Has:
ISRG Root X1
- Subject:
O = Internet Security Research Group, CN = ISRG Root X1- Key type:
RSA 4096- Validity: until 2030-06-04 (generated 2015-06-04)
- CA details: crt.sh, issued certs
But the cert is valid until 2035, not 2030
And:
ISRG Root X2
- Subject:
O = Internet Security Research Group, CN = ISRG Root X2- Key type:
ECDSA P-384- Validity: until 2035-09-04 (generated 2020-09-04)
- CA details: crt.sh, issued certs
Is valid until 2040, not 2035
I think it was an intentional choice, to describe "validity" (how long they expect it to be around for) rather than "notAfter" (what the self-signed cert says). I remember there being a (very) brief mention of it when they were asking for feedback on would became those pages, but I can't find it at the moment.
The certificates page contains a paragraph that explains this discrepancy:
Note that Root CAs don’t have expiration dates in quite the same way that other certificates do. Although their self-signed certificates do contain a notAfter date, Root Programs and Trust Stores may decide to trust a Root CA beyond that date, or terminate trust in it before that date. As such, the end-of-validity dates given below are approximate, based on current Root Program policies.
Yeah! That's what I had read somewhere. Thanks for digging it up. 
Note that I was concerned because this mismatch meant in my eyes that I was looking at the wrong cert in the browser.
May be worth clarifying "Intended to be used until", etc.
FWIW, I got some code that may need verification when the root CA is changed. That means that knowing when this is actually planned is important.
I could also see it being useful to list both. I know I've confirmed what certificates I'm looking at by comparing cert expiration dates in the past as well.
You and everyone else.
Roots aren't forever, and any trust store needs to have a plan to make changes. (Possibly suddenly, if it turns out that someone Mission Impossible'd into their datacenter and stole the keys, or if it turns out that they were made with a buggy random number generator, or even if Let's Encrypt runs out of funding and shuts down.) Like the Integration Guide says, "Plan for change", and also subscribe to the "API Announcements" category of this forum.
If your code need to know when specific roots expire that suggests your system has a potentially brittle dependency that carries some risk (ask me how I know!). You should be able to change CA (with a completely different or new root) at very short notice. CAs come and go and so do their roots.
My concern is how we'll handle switch over of the root CA when that happens.
It is an issue about automating "this is the same cert" when the cert is changed very 3 months.
So we rely on the chain still having the same root, but we need to know how that will change over time when it expires.
And yes, assuming it leaks, etc, that would be a surprise. But that is already something that is expected to be handled out of band, etc.
It sounds like you are implementing your own path validation for the certificate chain, presumably against your own trust store, is that right?
Somewhat, yes. We do client certificate auth, but we need to ensure that we keep track of the certificate as they change if they represent the same entity. We do that using the same key + chain, basically.
Let's Encrypt certificates are not really suitable for use as client certificates.
It's a bit complex, but basically, we do auth using X509 certificates.
Each server has a certificate, which we can use for TLS auth as well as a client certiicate.
Those are explicitly trusted, so not a chain of trust issue.
The problem is that they are short in duration, so we need to support refreshing them.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.