Elliptic Curve Cryptography (ECC) Support


Right now all of our root and intermediate keys use RSA. We’re planning to generate ECC keys and make an ECC option available to subscribers in 2016.


+1 excellent news indeed for ECC 256bit ECDSA :slight_smile:


I need it just now, when I can for apply?


@yon: I’m afraid ECC certficates are not available yet. When they become available (sometime in 2016), they will be available to everybody. Watch this space!


I am using IIS8.5 ,it not support DSA GCM,only support EC GCM,so I have to use EC.


Maybe where should be an difference between when CA use EC for their certificates on one side.
And on the other hand when client certificates are allowed to use EC certificates.


will the EC Root/Intermediate/whatever also be cross-signed?


Why doesn’t Let’s Encrypt offer ECDSA certificates earlier?

It shouldn’t be that hard to implement, right?:

  • It’s quite easy in existing open source software (i.e. OpenSSL);
  • It’s very well possible to sign ECC certificates (i.e. with an ECDSA public key) with a RSA signature, so there’s no need for Let’s Encrypt to wait for some key ceremony for their own ECDSA public/private key pairs or something…

I’d rather benefit now from the speed advantages of ECC than to wait for some time in 2016…


Does it really make sense to have ECDSA certificates signed by a RSA intermediate?


Only if the client store the intermediate. But even else it make sense since the RSA operation is slower than ecdsa and also more memory consuming. Each ECDSA step reduce the client load that is important for mobile devices.


by the way how looks ECDSA compatibility?


Hi at least each current browser support it. And many of the browsers support it.
So you can say it is more comman supported than TLSv1.2.


  • Android 4+
  • IE 7+
  • Java 7+
  • Openssl 1.0.0+
  • Safari 6+


I test ECC 256bit / ECDSA on my site at https://sslspdy.com including numbers for OS/browser compatibility as well

Browser compatibility with ECC 256 bit ECDSA

Unfortunately, ECC 256 bit SSL with ECDSA signatures isn’t supported on older browsers such as WinXP’s IE8 and below. You can use Google Analytics for your web property to determine your current number of WinXP related browser sessions and break them down by browser and browser versions.

For example, below Google Analytics stats show 507 total WinXP Internet Explorer browser sessions for IE <=8 were recorded out of 164,995 sessions. That’s just 0.3073% of browser sessions would be negatively impacted by deploying ECC 256 bit SSL certificates with ECDSA signatures. A small number, I can personally live with :slight_smile:

Update: according to Symantec, WinXP Chrome also doesn’t support ECC 256 bit SSL with ECDSA. That would raise the negative impact quite a bit with WinXP Chrome sessions amounting to 4,025 out of 164,995 sessions = 2.439%.

also FYI, alot of non browser clients may not support ECDSA as well i.e. older versions of curl <7.36 or some web app plugins that invoke curl i.e. Wordpress and WP Plugins

example with Cloudflare Universal SSL and ECDSA usage and Wordpress issues with curl https://community.centminmod.com/threads/wp-cron-ssl-connect-error-with-cloudflare-ssl-ecdsa.2276/

alot of server monitoring systems would have some type of client communicating with your server and some of those monitoring systems may not be able to connect if the client doesn’t support ECDSA too !


by the way is it possible to be able to use both EC and RSA (similar to the fact that multiple TLS versions can be used) I think I read some weird stuff about that in the comments of the apache config…


I’ve read Apache might in specific versions but haven’t seen specifics

Nginx doesn’t as openssl or libressl don’t support such. BoringSSL supports equal preference ciphers for ECDSA/RSA but haven’t tried. I only using Nginx with LibreSSL 2.2.4.

Wikimedia foundation has patched Nginx for multple SSL certificate support see http://forum.nginx.org/read.php?29,261089

Our configuration uses a pair of otherwise-identical RSA and ECDSA
keys and an external OCSP ssl_stapling_file (certs are from
GlobalSign, chain/OCSP info is identical in the pair). Our typical
relevant config fragment in the server section looks like this:

ssl_certificate /etc/ssl/localcerts/ecc-uni.wikimedia.org.chained.crt;
ssl_certificate_key /etc/ssl/private/ecc-uni.wikimedia.org.key;
ssl_certificate /etc/ssl/localcerts/uni.wikimedia.org.chained.crt;
ssl_certificate_key /etc/ssl/private/uni.wikimedia.org.key;
ssl_stapling on;
ssl_stapling_file /var/cache/ocsp/unified.ocsp;


New openssl support EC


yes it does… i think @My1 was asking about equal preference cipher negotiatons so clients that only support RSA certs get RSA certs and key exchange while clients that support ECDSA get ECC 256 bit certs etc.

my dream wish is for LibreSSL to support equal preference ciphers… nginx also has talked about adding such support. Fingers crossed as I would love to have RSA/ECDSA support simultaneously :slight_smile:


Actually it’s quite easy:

[quote]The next step was to configure Apache 2.4 to run in a dual RSA/ECDSA certificate configuration. This is actually quite simply – simple repeat the commands for the certificate/key twice within the same virtual host block (note: you should copy the intermediate certs and any DH parameters into the cert file):

SSLCertificateFile /etc/apache2/certs/ecdsa.cert.crt
SSLCertificateKeyFile /etc/apache2/certs/ecdsa.key.pem

SSLCertificateFile /etc/apache2/certs/rsa.cert.crt
SSLCertificateKeyFile /etc/apache2/certs/rsa.key.pem

From: https://blog.joelj.org/dual-rsaecdsa-certificates-in-apache-2-4/

Ofcourse you’ll probably also need OpenSSL 1.0.2. The blog mentions some strange things about the intermediate certificate string with 1.0.1…



I can not talk for openssl/libressl but for java i can say that this is already supported since at least java 5.
The keymanager in its newest version does not only select based on rsa/ecdsa the certificate but also on
Supported signatures, supported ec curves and key purpose. I think this should be possible with other ssl-apis too.


As with so many questions, the answer is: we’re trying to focus our offerings on one thing and launch that, then expand incrementally from there.

In order to offer ECDSA certs, we will need to hold another key generation ceremony, where we securely generate the signing keys in our HSM, recorded in front of witnesses. We also need to modify our “safe key” checks to do checks that are suitable for ECC keys, and provide a method for clients to indicate whether they would like an ECDSA cert or an RSA one (a small protocol change).

You can see, while it’s not a lot of work, it’s not trivial. But rest assured, we are just as excited about ECDSA certs as you are! I personally think they have a lot of potential to speed up TLS handshakes on low-bandwidth connections.