Gentoo Archives: gentoo-user

From: Matti Nykyri <matti.nykyri@×××.fi>
To: "gentoo-user@l.g.o" <gentoo-user@l.g.o>
Subject: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones
Date: Thu, 17 Apr 2014 05:59:59
Message-Id: AFB4327B-5EBE-422C-95BB-AB2014C8A69A@iki.fi
In Reply to: Re: [gentoo-user] Heartbleed fix - question re: replacing self-signed certs with real ones by Tanstaafl
1 On Apr 16, 2014, at 20:56, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
2
3 > On 4/16/2014 7:14 AM, Matti Nykyri <matti.nykyri@×××.fi> wrote:
4 >> On Apr 16, 2014, at 13:52, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
5 >>> Or will simply replacing my self-signed certs with the new real ones be good enough?
6 >
7 >> No it will not. Keys are te ones that have been compromised. You need
8 >> to create new keys. With those keys you need to create certificate
9 >> request. Then you send that request to certificate authority for
10 >> signing and publishing in their crl. When you receive the signed
11 >> certificate you can start using it with your key. Never send your key
12 >> to CA or expect to get a key from them.
13 >
14 > Ok, thanks...
15 >
16 Ok... This is the second time I'm writing this message. Last time my rotten battery of my rotten apple died while it was sending the message. That drove me to despair and i had sleep on it before retrying :/
17
18 > But... if I do this (create a new key-pair and CR), will this immediately invalidate my old ones (ie, will my current production server stop working until I get the new certs installed)?
19
20 No. Your cert is valid as described in the cert fields: not valid before, not valid after. You should never have two different valid certificates for the same propose. So it is the jobs of the CA to set the revoke bit on the old certificate when issuing a new one.
21
22 > I'm guessing not (or else there would be a lot of downtime for lots of sites involved) - but I've only ever done this once (created the key-pair, CR and self-signed keys) a long time ago, so want to make sure I don't shoot myself in the foot...
23
24 The same here. Now this heartbleed got me updating everything. There are a few very good tutorials... And if you skim back this list there was a really good post on certs like two weeks ago.
25
26 > I have created new self-=signed certs a couple of times since creating the original key-pair+CR, but never created a new key-pair/CR...
27
28 First you need to create parameters for your keys. If using elliptic key use:
29
30 openssl ecparam
31
32 This is not necessary for all types of keys. And usually most of these commands can be combined but I try to separate them so you get the full picture.
33
34 Then create keys:
35
36 openssl genpkey
37
38 Then make CR:
39
40 openssl req
41
42 After this the job is handled by the CA... So you for self signed cert. for a real cert you just send the CR to the CA.
43
44 CA will then sign your cert:
45
46 openssl ca
47
48 And publish your cert:
49
50 openssl ca -gencrl
51
52 For this CAcert is needed of course. If you just want a self signed cert you can create your own CAcert by creating keys and self-signed cert by:
53
54 openssl genpkey
55 openssl req -x509
56
57 Then sign and publish your CR with your CAcert using openssl ca-utility.
58
59 About security.. Your CA keys should never ever be on a computer that is online. If they were and would have been compromised by heartbleed for example we would be having a true catastrophe at the moment. Still it is suggested that you encrypt your CAcert keys.
60
61 >> There are also other algorithms the RSA. And also if you wan't to get
62 >> PFS you will need to consider your setup, certificate and security
63 >> model.
64 >
65 > What is PFS?
66
67 PFS = perfect forward secrecy. Meaning that the exposure of your cert keys will not compromise the content of past transmissions that have been recorded by your adversary.
68
69 This is offered by certain cipher suites. So you really need to consider what algorithms and what ciphers you wish to use with you SSL servers and choose certificates and parameters that will do the job.
70
71 DHE and ECDHE will provide PFS. I dont know enough about cryptography to truly say what to trust. Someone should correct me if my assumptions are false... But I have come to a conclusion that DHE is compromised by NSA. So I would not use it. DH and ECDH do not provide PFS.
72
73 Using PFS gives you a performance penalty but increase security. DH uses DHparams to do the key exchange. Openssl will reuse these params across different connection to boost performance. It needs to be explicitly told not to if this is desired. This again increases security but degrades performance.
74
75 For the cert I would use elliptic cryptography. I trust NSA has not poisoned this algorithm... But can you be sure? Anyways making things secure you need to trust that you have truly random data and there are no vulnerabilities in you key generators... It is really hard to make sure of this. It requires you to be a true pro.
76
77 -Matti