That doesn't really show what is being served.
Try SSL Labs.
2 Likes
The Chrome browser is also showing the same chain as the aforementioned tool, with the root certificate expiring on September 30th.
That's also a Windows (re)creation.
[not always the actual truth]
3 Likes
Do you have the Certify the Web client installed? I believe even if you're not using it to get the certs, having it installed will tweak the Windows cert stores so that it serves the correct chain.
3 Likes
SSL Labs showed the correct chain.
3 Likes
It also showed the long chain which wouldn't have happened without manual intervention on a Windows server.
2 Likes
OK so you're just trying to figure out HOW - got it.
2 Likes
I use Win-ACME.
From the SSL Labs test, it appears that the alternative chain is being used.
But the result also showed two possible paths, including the longest chain with root certificate that will expire tomorrow. I believe that as soon as the DST Root CA X3 certificate expires on September 30th, it will use the Cross-signed by DST Root CA X3 certificate.
Am I right?
Not exactly. It's confusing because the definition of "default" and "alternate" change depending on whether you're talking about ACME or Windows.
The "default" chain that Let's Encrypt serves via ACME is actually the longer chain that your server is serving (leaf + R3 + cross-signed ISRG root). But from a Windows perspective, that's not the default chain. When you import just the leaf certificate into Windows, it will build and serve the shorter "alternate" chain (leaf + R3) unless you already have the cross-signed ISRG Root in your Intermediate cert store. Most servers don't have this without external intervention, so it's possible Win-ACME did it.
I'm not exactly sure if Windows will continue serving the longer chain after tomorrow's DST expiration even with the cross-signed ISRG Root installed. But I'm inspired to go test it to make sure.
3 Likes
I reconfigured my test Server 2019 box to serve the longer chain and verified it was doing so. Then I set the date forward to Oct 2 and rebooted. Following the reboot with no other changes to the cert stores, it started serving the short chain. So at first glance, it appears at least IIS on Windows will not be able to serve the longer chain after the DST Root expiration. Though as observed during today's R3 expiration, it will likely continue to serve the long chain after expiration until it is either rebooted or something else convinces the underlying TLS library to re-evaluate the chain it is serving.
I'm gonna poke around a bit more and see if I can make it change its mind.
4 Likes
Sounds like some deep and secret reg key needs to be found/created ...
ValidateRootCertExpiryDate = 0
LOL
2 Likes
Although the SSL LABs result indicates that my Windows Server is serving the default (long) chain, my Android 8.1 client is using the alternative (short) chain.
While the Chrome browser on the Windows client is using something that resembles the long chain, but with the root certificate that expires on September 30. The strangest thing is immediately after the expiration of the R3 certificate, it was using the correct long string.
The question now is whether tomorrow the ISRG Root X1 certificate will continue to be considered valid when the DST Root CA X3 certificate expires.
Anyway, it seems pretty strange to me that every online system or tool is showing a totally different chain.
That's because the chain served by the server is not necessarily the chain that clients will use to validate. The chain you serve is effectively just a hint/suggestion that the client can choose to use or not. It's also why not serving a chain at all can still work for some clients. Bottom line, TLS client libraries vary widely in how they choose to validate a cert.
If you recall, there are two different certificates called ISRG Root X1 (using the same underlying key pair): the self-signed copy and the DST cross-signed copy. The self-signed copy will continue to be valid until it expires in 2035. Whether the cross-signed copy is considered valid will depend on the client library doing the validating...which is why it exists in the first place. The cert itself doesn't expire until 2024 and old Android versions don't care if the root certificate in a chain is expired.
4 Likes
Just a quick heads up, DST Root CA X3 is going to expire in 1 hour!
Given that the expired R3 already caused a bit of havoc, I expect the root expiry to be fun too.
2 Likes
Is it the same nice animation on the countdown page as with the intermediate cert yesterday?
2 Likes
Yeah it's the same code, I had no time for adjustments
2 Likes
As @rmbolger already found, Windows will fail to serve the longer android compatible chain when it realizes DST Root CA X3 is expired (which is not immediate), unless you make ISRG Root X1 Untrusted. Serving from Centralised Certificate Store doesn't help either. Oh well, we tried! Testing could have been better apparently.
So my expectation is that all devices which don't directly trust ISRG Root X1 will start failing to connect to Windows hosted services in the next 20 minutes.
On the bright side, this encourages people to move towards evergreen trust stores and to do maintenance on their neglected systems.
Looking forward to the countdown ending!
1 Like
Oh carp!
2 Likes
Technically, this would only be Windows hosted services like IIS that use the OS native TLS stack for chain building. If you happen to be running something like Apache on Windows that uses its own stack, you're probably fine.
Damn. That was gonna be my next test when I woke up this morning.
4 Likes