Maybe this good information is worth an pinned Information for some time on the start page. There are many people waiting for this feature.
1 Like
Hi @jsha!
ECDSA is a big win. 
I take it this means that youâve had your key signing ceremony and LEâs ECDSA CA is trusted?
Will somebody be updating this page with the new CA certs?
1 Like
Nope. We decided as an interim step to sign EC end-entity certs (aka leaf certs) using our RSA intermediates. Eventually, once we have a key signing ceremony and generate a new EC root and intermediates, and get a cross-signature, we will start signing EC EE certs with our EC intermediate.
3 Likes
Ah fair enough. Good to know! 
1 Like
Could you tell how do it ? I am using IIS8.5
1 Like
Not really since i have it integrated in my web server and do not use the official client.
1 Like
OK now i know that i need to be more carefully with hpkp
2 Likes
Hi @jsha are ecdsa keys also supported for use as registration keys?
1 Like
Yes they are I can confirm this even for production.
2 Likes
wow with EC keys and the new version of LE this might even run nicely on a pi 1b
1 Like
Do you know if I can provide certificate transparency information (I have latest Apache Ubuntu with latest OpenSSL) for two different certificates (an EC one and an RSA one)? How can I do that? Is that possible at all using some modification of cts-submit.php here?
1 Like
cts-submit you do not need at all. It publish your cert to the log server.
I think it should work the same like if you have different certificates for different domains.
How you make the CT available for one cert ?
1 Like
But resubmitting your cert to a log will get you your CTS. As Let's Encrypt currently doesn't have a method of retreiving the CTS of your cert, the resubmit-method is the only way I know..
2 Likes
Exactly. Then, I provide the SCTs with Apache TLS Extension. So, how can I provide two âbatchesâ of SCTs based on the certificate used?
1 Like
I tried to add another SSLOpenSSLConfCmd ServerInfoFile in the virtualhost, but i get some ssl errors from apache. There maybe some context problem i guess.
So after some tries, i âmergedâ with cts-cat.php the two tls extention in one and it seems to work. The downside is that as the extention provides signed logs for the two certificates, the client will get extra responses that are considered invalid.
But strangely chrome does not seems to be unhappy.
Does someone has the correct way to do this with apache ? (besides mod_ssl_ct)
1 Like
Thanks a lot for supporting ECDSA certificates! Now I can use authenticated ciphers (AES_GCM) on IIS (WinSvr2012R2) and on the IE11 clients on Win7/8.1.
For my own sites, I took the opportunity of using a ECDSA certificate to disable TLS 1.0 and 1.1 and all non-AEAD ciphers like AES_CBC (as, according to Adam Langley, "everything less than TLS 1.2 with an AEAD cipher suite is cryptographically brokenâ). This means some older clients cannot connect to it (e.g. Safari on OSX 10.10), however IE11 on Win7 can connect, so this is OK for me.
Because browsers like Firefox and Chrome donât use AES256_GCM (as the security benefits of AES256 are not to be worth the performance tradeoff, as stated on a chromium bug entry) and a P-256 ECC key only provides ~128 bit symmtric key strength, I also disabled AES256, and because Chacha20_Poly1305 is not yet supported on SChannel, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 remains as the only available cipher. 
Here is the Ssllabs report for one of my sites.
2 Likes
@T917820981726, just OCSP Stapling doesnât seem to work for the site you refer. Everything else looks good (however, you just issued a 256-bit ECDSA key and not a 384-bit one ⌠would have gained extra points in the SSL Labs test. (100/100/100/80), and offering AES256_GCM in addition would have brought you a 100/100/100/90. Just for the scoring nerds. 
1 Like
Exactly. And FYI this config is better than the one of suche.org by @tlussnig. Do not mind that you do not get 100% everywhere, thatâs not what you want.
FYI Firefox chooses a SHA-1 HMAC on suche.org, which is not really secure. That is why you should not follow such 100% guidesâŚ
BTW the more important reason to use AES with 128bit than 265bit is that the 256bit version may in fact be less secure than the 128bit version, because timing attacks are probably possible.
@ecdsa-chacha20 No, not âgain extra pointsâ. 384bit ECDSA key is unnecessary and as explained above AES256_GCM may be less secure than AES128_GCM.
But I agree that OCSP stapling could be enabled and possibly certificate transparency.
2 Likes
As far as I know, those attacks on 256 bit AES were with variants of AES with less rounds than the officially used cipher.. So yes, there are attacks possible on AES, but those shortcomings aren't usable in the wild, because the variants used in the attacks were artificially weakened.
1 Like
Do you have any sources, which support your claim?
My is this: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
It is old but as @jvehent said in the GitHub issue:
it doesn't seem like the state of the art has changed since [two years]
Obviously you may always suggest a change of the prioritisation in this issue or in Mozillas repo.
And if your comment is valid it even does only mean that AES 265bit is not less secure than 128bit, which still means that there is no advantage of AES 265bit.
And as you see there was already a discussion there.
1 Like