Remove Expired Root Certificates from NSS - DST Root CA X3
Categories
(NSS :: CA Certificates Code, task, P1)
Tracking
(Not tracked)
People
(Reporter: ddick, Assigned: beurdouche)
References
Details
Attachments
(2 files)
Please remove the following expired root certificate from NSS:
CN=DST Root CA X3,O=Digital Signature Trust Co.
DB Key : AAAAAAAAAAAAAAAQAAAAQUSvsIDWoye6iTA5hi74QGswPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMw==
Valid to : 30/09/2021
Certificate Serial Number: 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B
SHA-1 Fingerprint : DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
SHA-256 Fingerprint : 06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
This certificate appears to be on one of the chains of trust for Let's Encrypt.
| Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Hi,
I'd like to ask the same thing : please remove the expired "DST Root CA X3" from the file
./nss-3.72/nss/lib/ckfw/builtins/certdata.txt
That file (certdata.txt) is used by the OpenIndiana operating system to create an OpenIndiana package called crypto/ca-certificates.
The file nss-3.72 certdata.txt has an entry for a certificate that expired after 21 years in september 2021.
This poses a problem for platforms using openssl 1.0.2 such as OpenIndiana and accessing web sites that use certificates signed by the expired root certificate.
As an example I have attached a log session of the following command that shows/ illustrates the problem.
openssl s_client -showcerts -connect squeaksource.com:443
See the file bugzilla-log-1733560 in attach.
Also https://letsencrypt.org/images/isrg-hierarchy.png as in the original report and
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
https://access.redhat.com/articles/6338021
Thank you!
Comment 3•4 years ago
|
||
| Assignee | ||
Comment 4•4 years ago
•
|
||
This is planned for December batch of updates (see Bug 1733003).
I am not sure I understand what the situation with OpenSSL is here, it seems to correctly say that the root expired...
Is the problem that OpenSSL doesn't enforce the root expiration check on misconfigured servers that send the incorrect LE chain?
Comment 5•4 years ago
|
||
Thank you for your feedback.
For example the website https://squeak.org is running a server certificate signed by DST Root CA X3 and DST Root CA X1
My understanding is that openssl 1.0.2zb or openssl 1.1 considers this as "trusted" because it is signed by the non-expired X1 certificate.
However the openssl 1.0.2 software prefers the expired X3 and considers the connection "untrusted" and this gives an error in some application software such as the OpenSSL plugin for Squeak Smalltalk when it connects to the the https://squeak.org server.
See the blog https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ for more info.
In any case thanks for the feedback and hopefully the certdata.txt file can be updated please.
This can be done in December but I had been hoping that it was in the just released NSS 3.72 which was released yesterday Oct 28.
Would it please be possible to assign this bug 1733560 to some assignee please ?
Regards,
David Stes
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 6•4 years ago
|
||
Kathleen, any thoughts on this? What would you think of removing the expired roots prior to the December batch?
Comment 7•4 years ago
|
||
It's fine to remove it now. This root cert only has the Websites trust bit enabled, and is not EV.
Comment 8•4 years ago
|
||
That said, this does seem like an instance of https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/ where if the downstream consumer is incompatible with expired roots (e.g. due to path building), they should be filtering those out themselves. It’s totally reasonable to bump this forward, but it seems longer-term, this is an issue in how OpenIndiana consumes the store.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
| Assignee | ||
Comment 10•4 years ago
|
||
Description
•