Hi, I got the email that my account is now on the allow list. What do I need to do to test this in the staging environment. When I tried certbot --dry-run I still get an RSA certificate.
Update: I had to use certbot --key-type ecdsa --cert-name wiki.tnonline.net --dry-run to force conversion from RSA to ECDSA.
Question: Will this go automatically during next renewal?
An RSA cert will always be renewed as RSA, an ECDSA cert will always be renewed as ECDSA.
The allow list only impacts the intermediate from which ECDSA certs are issued: E1 instead of R3.
(but RSA certs will continue to be issued from R3, even if you're on the ECDSA allow list.)
Thank you. How would I migrate to ecdsa using certbot?
In renewal/mysite.conf I've added key-type = ecdsa and elliptic-curve = secp384r1
Don't renew, just create a new ECDSA certificate using the same hostname(s).
Congratulations!
And then I might add, if you're switching entirely to ECDSA (rather than running both RSA and ECDSA in parallel), once your server is no longer using the RSA certificate you should probably delete it from certbot since you won't need to renew it in the future.
Indeed. This is my plan.
One of the reasons I wanted to move to ECDSA is because it has a broader compatibility than RSA certificates when using Caddy webserver with TLS 1.1/1.2. Especially IE on Windows 7 was important as I've had clients not being able to connect.
With RSA certificates:
With ECDSA certificates I now get:
Well, it's a different set of compatibility tradeoffs (and in general RSA is more compatible than ECDSA), and you can use an ECDSA or RSA leaf certificate regardless of whether you've signed up for this allow-list that just changes which intermediate Let's Encrypt uses for signing.
I wouldn't switch to ECDSA just purely on ssllabs's handshake simulator, whether systems are can handshake successfully is much more about which cipher suites your server supports, which is kinda related to your leaf key type but has many more factors involved as well. I'd generally recommend looking at Mozilla's Recommended configuration and Configuration generator tool for what ciphers suites you should enable to work with various clients.
Indeed. Caddy is rather limited here, so it wasn't possible to add the cipher suite so older clients were supported with RSA. Specifically DHE-RSA-AES256-GCM-SHA384.
This is 100% true, not arguing with this, however there's one important aspect to @Forza's configuration, which is also highlighted in Mozilla's Server Side TLS config:
ECDSA certificates are recommended over RSA certificates, as they allow the use of ECDHE with Windows 7 clients using Internet Explorer 11, as well as allow connections from IE11 on Windows Server 2008 R2
Effectively, Mozilla's current policy version 5 recommends to only allow the usage of AEAD ciphers in their intermediate configuration*. And while AEAD does have pretty good support for modern devices, old devices sometimes do not have good support for AEAD. This is the reason why the screenshot above shows failures for older iOS/macOS devices.
IE11 on Win 7 has some strange default config, where it does support AEAD + ECDHE with ECDSA certificates, but doesn't do with RSA certificates. This is the reason why ECDSA is considered to be more compatible in this specific scenario. So @Forza is not incorrect here.
I generally recommend dual certificates (ECDSA + RSA) for broad compatibility, and also at least one non-AEAD cipher. This is against Mozilla's recommended intermediate config, but it's much more compatible - and the difference in security is negligible (if server side cipher suite preference is enabled with a good order).
*The benefit of only allowing AEAD is that you can turn off server side ciphersuite preferences, without loosing security. When enabling non-AEAD, server side preferences are required again, which makes things like preferring ChaCha on devices without AES hardware acceleration more difficult.
This cipher suite is rather unusual, as it implies a device without ECC support, but with AEAD support. I rarely see this negotiated in practice. Enabling a non-AEAD cipher definetly increases compatibility on old devices.
As mentioned above, that's exactly IE11's (strange) behaviour: Qualys SSL Labs - Projects / User Agent Capabilities: IE 11 / Win 7
Thanks for the explanation; it's been a long time since I've needed to care about Windows 7. 
But regardless, the differences in compatibility are entirely about which key type you use for your own cert, and not which intermediate Let's Encrypt is uses? The only compatibility issue I've heard of is the Android version that doesn't handle the P-384 signatures, so if one needs to support that version than one should use ECDSA P-256 with the default RSA chain (or all RSA) instead of signing up for this allow-list. But other than that, it shouldn't matter from a compatibility perspective whether one is on it or not, right? Or is there even more for me to go read up about?
Correct, this IE11 compat issue is purely about certificate type and corresponding cipher suite configuration, not about the certificate chain.
But @Forza was switching to an ECDSA certificate and the ECDSA chain at the same time, hence this discussion.
With regards to cipher suites, yes. On TLSv1.2, the cipher suite signature algorithm (RSA/ECDSA) needs to match the one from the cert. The exact elliptic curve used is not negotiated in the cipher suite, though clients can indicate what they support (supported groups extension and others).
Though this is only what the standards say and Microsoft apparently doesn't care too much about those. As I write, I recall that Microsoft used to actually encode the elliptic curve in the internal cipher suite!
(This is solely an internal config thing and has no impact on protocol level cipher suite naming/handling)
That's a very temporary solution though, as Let's Encrypt isn't going to keep the allow-list forever.
As for the Android 7.0 bug, I no longer have access to a test device and it's been some years since I checked the facts, but I believe the BoringSSL version shipped there explicitly states that it will only handle P-256 (in the signature_algorithms extension, or via the supported_groups extension - not sure, maybe both).
OpenSSL servers (at least partially) respect this, but only with regards to the leaf certificate. So if your server is sending a P-256 leaf, but your issuer is P-384, OpenSSL will send the ECDSA certificate, even though that fails on a 7.0 device. However, if your ECDSA leaf is also P-384, OpenSSL should see the incompatibility and fall back to RSA certs, if those are available.
So in theory the 7.0 bug can be worked around by using P-384 leafs and having a fallback RSA ready. Writing this, this makes me considering if I should switch my current ECDSA leafs to P-384. But on the other hand, 7.0 doesn't trust ISRG Root X1 anyway, so the chain offered by LE won't validate by default. Also note that this is only a theory - I was unable to validate this, as my Android 7.0 emulator ships a patched version that handles P-384 just fine (this is also what Qualys states for 7.0) - which is not the case for all real-world 7.0 devices.
[To add to all this confusion, we need to remember that there are actually two algorithms involved that may use ECC: The ECDH(E) key exchange and the ECDSA algorithm. Those algorithms may use different curves in the handshake and may also not support the same ones - in fact, some curves like Curve25519 are not supposed to be used with ECDSA (they're used together with EdDSA)]
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
