On Apr 17, 2014, at 9:10, Mick <michaelkintz...@gmail.com> wrote: > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote: >> On 4/16/2014 7:14 AM, Matti Nykyri <matti.nyk...@iki.fi> wrote: >>> On Apr 16, 2014, at 13:52, Tanstaafl <tansta...@libertytrek.org> wrote: >>>> Or will simply replacing my self-signed certs with the new real ones be >>>> good enough? >>> >>> No it will not. Keys are te ones that have been compromised. You need >>> to create new keys. With those keys you need to create certificate >>> request. Then you send that request to certificate authority for >>> signing and publishing in their crl. When you receive the signed >>> certificate you can start using it with your key. Never send your key >>> to CA or expect to get a key from them. >> >> Ok, thanks... >> >> 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)? > > You have not explained your PKI set up. Creating a new private key and CSR > is > just another private key and CSR. > > If you replace either the private CA key on the server, or any of its > certificates chain, but leave the path in your vhosts pointing to the old > key/certificate that no longer exist you will of course break the server. > Apache will refuse to restart and warn you about borked paths. > > >> 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... > > Yes, better be safe with production machines. However, don't take too long > because your private key(s) are potentially already compromised. > > >> 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... >> >>> There are also other algorithms the RSA. And also if you wan't to get >>> PFS you will need to consider your setup, certificate and security >>> model. >> >> What is PFS? > > http://en.wikipedia.org/wiki/Forward_secrecy > > I'm no mathematical genius to understand cryptography at anything more than a > superficial level, but I thought that ECDS, that PFS for TLS depends on, was > compromised from inception by the NSA? Perhaps only some ECDS were, I am not > really sure.
I don't know anything about ECDS. You probably mean ECDSA?! What i have understood is that ECDSA is not compromised. Though I can not be certain about that. RSA has been in the market for a long time and the mathematics are for what i think a bit simpler. But with compromised software there was a bad algorithm for creating the primes. So it was the keys not RSA it self. But I think the thing that you are talking about is DHE_RSA... I read from somewhere that it was quite compromised.. But ECDHE is not. The difference with DH and DHE (ECDH and ECDHE) is that DH uses static keys and DHE authenticated ephemeral keys. These temporary keys give you forward secrecy but decrease performance. RSA takes quite heavy computing for the same level of security compared to ECDSA. RSA key creation is even more costly so using ephemeral temporary keys with RSA takes quite long to compute. Thats why I prefer ECDHE_ECDSA suites for reasonable security and fast encryption. > I remember reading somewhere (was it Schneier?) that RSA is probably a better > bet these days. I'd also appreciate some views from the better informed > members of the list because there's a lot of FUD and tin hats flying around > in > the post Snowden era. For high security application I would also use RSA in excess of 16k keys. Then make sure to use random data and a trustworthy key-generator. Fighting the agencies is still something I believe is virtually impossible ;) -- -Matti
