Can some one explain how renewal expiration of R3 works?

Help
1

The certificate chain that is being issued currently via traefik and cert manager have intermediate R3 and Root DST Root CA X3 expiring at the end of the month. I have seen and read the thread here: Production Chain Changes

Can someone explains to me what will happen to my LE certificate that is expiring in December once the R3 and Root it based on expire at the end of the month? The monitoring software (Logic Monitor) is telling me that the certificate will stop being valid when this happens. How do I get a certificate that will be valid past the current R3 and DST Root CA X3 expiration? May be I configured traefik / certmanager improperly so I'm getting the cert signed by the soon expired certificate chain? How is this supposed to work?

Many thanks,
Andrew

1 Like
2

Welcome Back to the Let's Encrypt Community, Andrew :slightly_smiling_face:

It sounds like currently your server is currently serving the following:

Your server should be serving the following:

Both assume that your visitors have DST Root CA X3 in their trust stores.

1 Like
3

As per the linked page, you should currently be using R3 signed by ISRG Root X1, which is valid until Sep 15 16:00:00 2025 GMT. This certificate is send by the ACME server for every issuance since May.

There's another version of R3, signed by DST Root CA X3 which is no longer valid after the months end. Your ACME client should not be using this certificate anymore.

3 Likes
4

Yes, that's right. Windows seem to display the trust chain incorrectly for some reason. The chain that is shown in Windows UI is not the same as what I see when I examine the certs from command line. The latter shows what you just described.

3 Likes
5

Please use the following tool to see what is actually being served by your server:

https://www.digicert.com/help/

1 Like
6

Will this work on a server is not externally accessible?

1 Like
7

Unfortunately not. Why not use a private CA for that?

1 Like
8

Or perhaps a better question...why would you when Let's Encrypt is so awesome?

2 Likes
9

Because expirations and such can be handled much more easily with a private CA?

1 Like
10

Bah, automation means expirations don't matter. Standing up, securing, and maintaining a whole CA for a few internal certificates is way more effort than just using an ACME client if you can deal with DNS validation.

4 Likes
11

Expirations of intermediates (and roots), like here, certainly matter.

One must accept the pain with the awesomeness. :man_shrugging:

2 Likes
12

If the servers are "internal" enough, it might also be possible to simply forgo TLS/SSL entirely, thus avoiding the efforts and concerns altogether.

1 Like
13

I agree with @rmbolger on this one. But we digress...
If it can be secured (FREELY) in an automated fashion, then why not?
[regardless of any other pro or con - and there are plenty]

1 Like
14

After a digging a bit deeper, what happened was:

  • Everything behaved as expected from LE perspective in terms of certificate generation. The chain contained up to date certificates with correct Intermediate and Root certs
  • The issues was local to Windows Boxes running IIS (Internet Information Server). The IIS would serve the incorrect certificate chain with older certs.
  • Both the old and the new certs were present on the Windows certificate store. In a parallel thread on this forum someone suggested, that when the old certs expire, the issue will go away by itself
  • To test the above I have removed the expiring R3 cert from one of the boxes and rebooted it. Upon reboot the web site started to serve the expected certificate chain.

Thank you everyone for contributions.

On the topic of "Why not use a private CA for that?", it's pretty simple, because it requires time to set up and maintain, whereas the existing solution is already in place and has proven successful over the last few years.

4 Likes
15

Yeah the primary issue with the expiring R3 on windows is that Windows prefers it when building a verified chain due to the expiring one being both valid and having the newer issue date, it doesn't care (yet) that the other R3 has a further/better expiration date. There is a certain amount of "wait-and-see and reboot if it doesn't work" going on here.

1 Like
16

That is a very interesting detail "upon reboot".
It's still left to be seen if IIS will be "smart enough" to switch to the newer path without a reboot.
[highly unlikely but who knows? - maybe someone can forward the clock to see what IIS does in a lab]

OR
Maybe a PowerShell script can be made to remove the expiring cert and restart IIS.

2 Likes
17

I actually did not try it before rebooting. Common sense and experience tell me that there is a good chance that restarting IIS without a reboot would work as well.

1 Like
18

My own testing was in the future, but I didn't try letting the system tick over from unexpired to expired, I just set a future date on the client and server then tested, so that could be something to try.

2 Likes
19

Yes, but even that requires admin interaction/intervention.
I'm thinking about all the servers that don't get that much attention...
How long will they be serving the old path (if chosen only at startup)?

2 Likes
20

I did try restarting IIS in my tests but the issue is higher up the food chain at the kernel level somewhere in https.sys/CAPI, there may be a service that could be restarted without restarting the whole server but I didn't figure out which.

2 Likes