When running certbot renew, I'm getting a failure in talking to acme-v02.api.letsencrypt.org:443.
Certbot logs show:
Failed to renew certificate mail.crc.id.au with error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1000)')))
If I try to access the directory URL with curl, it fails with a similar error:
$ curl -v https://acme-v02.api.letsencrypt.org/directory
* Host acme-v02.api.letsencrypt.org:443 was resolved.
* IPv6: 2606:4700:60:0:f53d:5624:85c7:3a2c
* IPv4: 172.65.32.248
* Trying [2606:4700:60:0:f53d:5624:85c7:3a2c]:443...
* Connected to acme-v02.api.letsencrypt.org (2606:4700:60:0:f53d:5624:85c7:3a2c) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, bad certificate (554):
* SSL certificate problem: EE certificate key too weak
* Closing connection
curl: (60) SSL certificate problem: EE certificate key too weak
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
I'm doing all this on Fedora 40 - and can't say I've run into this before...
Has anyone come across this and managed to fix it somehow?
Hunting further, it seems that the system crypto policies are set higher than LetsEncrypt support.
# update-crypto-policies --show
FUTURE
I managed to fix this setting the policy back to DEFAULT via:
# update-crypto-policies --set DEFAULT
At this point, running certbot renew works correctly.
Something must have changed in the crypto policy to exclude the certs that LetsEncrypt use on their systems.
The down side is if you want to use a higher policy than LetsEncrypt supports, then you'll have to configure each application manually and not rely on the system cipher set.
Note that this is not a Let's Encrypt support issue per se, but simply that the FUTURE policy requires "RSA keys size: >= 3072" where the intermediate certs are 2048 bits.
I'm not sure why OpenSSL didn't simply accept the ECDSA cert though, as the intermediate certs have ECDSA keys of 384 bits? The FUTURE policy says "Curves: all prime >= 255 bits (including Bernstein curves)", but also "TLS Ciphers: >= 256-bit key (…)". Is that latter bit size the "symmetric equivalent" perhaps?
I don't know why; I just only see the RSA intermediates in its history which I would think indicates they're only using RSA leafs too. I'm guessing it's because RSA is still the most compatible and they wouldn't want to change it (even to using dual RSA/ECDSA certs) without warning, and changing may be more of a hassle than it's worth.
At the risk of speaking out of turn here, given that the FUTURE crypto policies required better than the RSA that is already enabled, would it be a good idea to start working towards a dual RSA / ECDSA certs on these systems to further future-proof them?
ie get ahead of the issue before it becomes more pressing over time.
Frankly I don’t think disallowing 2048 bit RSA on the internet today is feasible, but we do have a ticket in the backlog to enable ECDSA and clean up a bit of cruft in our accepted cipher suites. It’s not at the top of the backlog and may not get handled for some months yet, though.
You might be right. In fact, you probably are right.
That's the whole point of the FUTURE cipher suite policy - is that its future looking.
At least having something in process now will allow time for this to filter through without being in a panic - which is a much nicer and lower stress option
I don't think anyone is going to care that its a 6-12 month implementation timeline - as even that would probably be just fine for everyday users / adoptions.
Most of my tests are running the FUTURE cipher set and TLS1.3 only - which again, would cause major issues for a lot of everyday users at this point.
