The current certificate chain that LetsEncrypt's certbot install, is invalid. This chain creates all sorts of issues with vulnerability scanners that we now have to address. We cannot rely on client-side devices to verify the chain of trust.
Please provide a valid chain of trust that will automatically install onto our servers.
@francoisj , welcome to the community!
The default certificate chain provided be Letsencrypt should be fine for most cases. Known exception is having some old openssl implementation that aborts searching for supplementary trust path when it encounters expired root certificate.
You may want to select the alternate chain that does not contain the certificate pointing to the expired root certificate. However, you may loose old android phone compatibility.
Anyhow, may be an update for the vulnerability scanner could help to remove the incorrectly reported issue?
The vulnerability scanners are wrong. There are a few previous threads on the forum if you search around which have some tools complaining about the root certificate that Let's Encrypt's default chain uses, but a lot of careful thought and work went into the choice of chain, to maximize compatibility with as many devices as possible.
As mentioned, you have the option to use the alternate chain with Certbot which chains only to the modern "ISRG Root X1" root:
--preferred-chain "ISRG Root X1"
That said, will LE be bothering to renew the current ISRG Root X1 cross signed by DST Root CA X3, expiring Sept 2024?
For the next release of our app we're planning to default to preferring the ISRG Root X1 chain for LE because it doesn't really make much sense on Windows and causes confusion when people export their cert chain to other devices/certificate stores. I'm not sure if we have current stats for the number of devices still in circulation which require the DST Root CA X3 workaround but perhaps clients could set this as their preferred chain, rather than having it as the default.
I disagree that this is an incorrectly reported issue. The certificate chain provided by the server is invalid because the root certificate expired. As simple as that.
It's not as simple as that. Please read more about the difference between a root certificate and a trust anchor. Thank you.
Have a read of https://letsencrypt.org/2020/12/21/extending-android-compatibility.html:
But isn’t DST Root CA X3 expiring? The self-signed certificate which represents the DST Root CA X3 keypair is expiring. But browser and OS root stores don’t contain certificates per se, they contain “trust anchors”, and the standards for verifying certificates allow implementations to choose whether or not to use fields on trust anchors. Android has intentionally chosen not to use the notAfter field of trust anchors. Just as our ISRG Root X1 hasn’t been added to older Android trust stores, DST Root CA X3 hasn’t been removed. So it can issue a cross-sign whose validity extends beyond the expiration of its own self-signed certificate without any issues.
That seems to be OK as a naive, first approach. However, there is full RFC dedicated to the topic: RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building
If the security scanner issues a debug level statement about it, it is still OK, something like:
-- DEBUG -- while building trust path the certificate A, expired root certificate 'DST Root CA X3' encountered, continuing
-- DEBUG -- found valid path to certificate A pointing to 'ISRG Root X1'
I don’t think that decision has been made yet. It’s not one to be taken lightly, with significant compliance and compatibility implications, and there’s good reason to choose both options.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.