My issue is not old device compatibility. It is that sites we host are tested by our customers using ssllabs and they see the following:
(in path #2)
Sent by server
ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
RSA 4096 bits (e 65537) / SHA256withRSA
CRL ERROR: HTTP request failed with status code 404: http://crl.identrust.com/DSTROOTCAX3CRL.crl
In trust store
DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
Weak or insecure signature, but no impact on root certificate
They also do vulnerability scans using Nessus, and that is flagging a SSL problem as a high level vulnerability.
We host on AWS using Ubuntu - for the example above, the server has been completely updated/rebooted, and I re-issued the certificate.
Is there any way to fix this or do I need to switch certificate issuers?
IMHO the cert chain should not contain the "ISRG Root X1" cert all but ONLY the Intermediate R3 cert.
Including the X1 root cert was only required for the DST cross siging situation.
Now with the DST cert being expired, this is causing just problems if the DST issued X1 cert is included in the chain.
@Letsencrypt: How about reducing the cert chain to R3 now only? This would solve a lot of problems I think.
They have a shorter alternate chain that is Leaf <-> R3 <-> ISRG Root X1 that you can opt into if you'd like.
It comes with its own problem though: ISRG Root X1 is not trusted on Android < 7.1.1, which is why Let's Encrypt is defaulting to the longer chain.
There's also really old iPads and iMacs that don't trust ISRG Root X1 either -- we've had a few people using those devices submit support requests too.
but systems which don't trust the "ISRG Root X1" root are out now in any case.
Shipping the DST issued ISRG Root X1 was only helpful for those old devices as long as the DST was not expired.
Now the DST issued ISRG Root X1 is causing trust errors even on devices that DO trust the ISRG Root X1 root. I've seen Firewalls, which fail with that and also "apt" from Ubuntu 20.04 for example fails with te DST issued ISRG Root X1 cert in the trust chain.
If you want to ship the "ISRG Root X1", then you should ship the selfsigned version and not the one issued by the expired DST root. But as I tried ro explain before - it does not help anyone now to ship the "ISRG Root X1" in the chain, now that this can no longer be used as an intermadiate trust cert with the DST root faded.
That is incorrect. The old Android devices that the default long chain is intended to address do not care that the DST root is expired. It's a quirk of those implementations that Let's Encrypt is taking advantage of.
Most other modern clients either short circuit the validation and stop when they reach ISRG Root X1 which is already in their trusted roots or they fail the initial validation against DST Root CA X3 and then try a different path which ends in ISRG Root X1. This is effectively what you see when using the Qualys SSL Labs test.
Our clients know we do not support older devices or browsers for the sites we host for them. So then regarding my post/question about our clients that look at the ssllabs results - and Nessus vulnerability scan results - both of which flag an issue... I have to go into great detail about the cause and that in our case it is a non-issue/false-positive. Some InfoSec departments of these large corporations don't want to hear it or believe us when we tell them. They just want the risk flagged to be "fixed". The only way I can think of now is to use a different CA. Am I wrong?
If your sites do not need the old Android support provided by the long default chain, you can use the shorter alternate chain that does not have anything to do with the expired DST Root CA X3. I'm not sure what Nessus shows for sites serving the short chain, but SSL Labs shows no chain related errors or warnings when using it. You can see an example using the
valid-isrgrootx1.letsencrypt.org site which serves the short chain.
Note. I stress "chain related" errors. Because the SSL Labs example for that site shows other web server related warnings because it allows legacy TLS protocol versions that don't have anything to do with the cert or chain being served.
Using certbot on Ubuntu and Nginx to generate certs, how do I specify or force to use only the short chain. tried certbot --preferred-chain "ISRG Root X1", but without success.
Can you be more specific about what you mean by "without success"? Was there an error? Did everything seem to work but your site is still serving the long chain? What versions of certbot, Ubuntu, and Nginx are you using? How does your Nginx config reference your cert/chain files (can you post an excerpt of the relevant config)? I may not be able to personally help diagnose your problem, but these details will help other folks here help you.
This is what I mean by without success:
$ sudo certbot --preferred-chain "ISRG Root X1"
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certbot: error: unrecognized arguments: --preferred-chain ISRG Root X1
nginx conf references cert/chain this way:
ssl_certificate /etc/letsencrypt/live/paninikidreporter.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/paninikidreporter.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
Ubuntu 18.04.6 LTS
Welcome to the Let's Encrypt Community, Kevin
Your certbot version (0.31.0) is very old and doesn't support the
--preferred-chain was introduced into
certbot at version 1.12.0.
Not sure what is going on then...
$ sudo apt-get install --only-upgrade certbot
Reading package lists... Done
Building dependency tree
Reading state information... Done
certbot is already the newest version (0.31.0-2~deb10u1+ubuntu18.04.1+certbot+3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
You may need to remove that version of
certbot and install the
snap version of
See: Certbot - Ubuntubionic Other (eff.org)
You can switch to another ACME client (like:
ok. This is all slightly over my head, but uninstalled, then got the snap version installed. was able to reissue the cert using the --preferred-chain option. And obviously it only has the short chan in the ssllabs results. I am sure the Nessus scan will not flag the vulnerability either.
A bit of a PITA though. If I don't do this though, try explaining the vulnerabilities flagged in the quarterly scan to the ISO 27001 auditor... It just suck we have so many servers running with let's encrypt certs...
Sounds to me like some auditors need some training. Just my 2¢.
They can start here:
They look at "the evidence" (read: "the results of the scans"), and Nessus calls it a high level vulnerability. And so I have to explain everything the auditors, I have to explain everything to client's infosec departments... It gets to be a burden having to defend my "false-positive" statements on conference calls with infosec people who are not aware of what is going on and account people who have no clue other then they saw "high level vulnerability" on an official looking report.
I get it, my friend.
Some people just see the yellow or red and don't really care what's behind it. I feel your pain.
If you find that you need to, you can refer whoever to the link I provided in my previous post to the article I wrote. It explains fairly concisely exactly the nature of the situation.
You can also switch to certs from another (free) ACME friendly CA .
I have become very comfortable with Let's and certbot, but .... such as ... ?