On Thu, Apr 17, 2014 at 04:49:45PM +0100, Mick wrote: > On Thursday 17 Apr 2014 15:40:04 Matti Nykyri wrote: > > On Apr 17, 2014, at 9:10, Mick wrote: > > > On Wednesday 16 Apr 2014 18:56:57 Tanstaafl wrote: > > >> On 4/16/2014 7:14 AM, Matti Nykyri wrote: > > >>> On Apr 16, 2014, at 13:52, Tanstaafl 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 > > ;) > > Thanks Matti, > > Can you please share how you create ECDHE_ECDSA with openssl ecparam, or ping > a URL if that is more convenient? Select curve for ECDSA: openssl ecparam -out ec_param.pem -name secp521r1 Create your own CA certificate and associated new pkey: openssl req -new -x509 -extensions v3_ca -newkey ec:ec_param.pem -keyout private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf #create cert request and new pkey: openssl req -new -nodes -out req.pem -newkey ec:ec_param.pem -config ./openssl.cnf #sign cert with your CAcert: openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem #create crl for all certificate requests you have signed with your CAcert: openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl #revoke certificate: openssl ca -revoke newcerts/.pem -config ./openssl.cnf Modify openssl.cnf to suite your setup. With this setup you will get the newest fastest and most secure cipher by public sources: ECDHE-ECDSA-AES256-GCM-SHA384 I don't know much about the secp521r1 curve or about its security. You can list all available curves by: openssl ecparam -list_curves With this setup apache and postfix works great. You can test my server with this URL: https://www.ssllabs.com/ssltest/analyze.html?d=nykyri.eu&hideResults=on So these ciphers are supported: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH 256 bits (eq. 3072 bits RSA) FS 256 I still have alternate names not setup and few other things neew changing with the certificates, but this might change during Easter :) The tutorial I mentioned before is here: http://www.eclectica.ca/howto/ssl-cert-howto.php The one problem I have is that no matter what I have failed to get courier to support ECDHE. Courier needs the DHparams for ephemeral keys to work, but I have failed to set it up... so there I have TLS_ECDH_ECDSA_WITH_256_GCM_SHA384 :/ Will continue trying... To create dhparameters: openssl dhparam -out dhparam.pem 4096 And you will find openssl.cnf attached :) Create a directory and put it there. Under that create directories private, newcerts. Then create files: echo 01 > serial touch index.txt -- -Matti