Obtaining a letsencryp certificate with the old intermediate "X3"?

Issuance Tech
#1

Hello all,

we were running a letsencrypt certificate on a server that used to me signed by the intermediate "Letsencrypt Certificate Authority X3". A number of machines "in the field" were doing certificate pinning to the old certificate chain.
Apparently an update between 2020-12-20 and 2021-01-03 changed the intermediate from "Letsencrypt Certificate Authority X3" to "R3" and now those machines refuse to talk to our server.

Is there a way to get a certificate issued which uses the "Letsencrypt Certificate Authority X3" as the intermediate certification authority?

Thanks,
Christian.

1 Like
Issue from multiple intermediates during a scheduled transition period?
Keep "Let's Encrypt Authority X3" for renewed certificate
#2

Hello @cts,

I'm afraid it is not possible. In this post you could see a similar issue and the LE staff responses saying it is not possible.

Cheers,
sahsanu

4 Likes
#3

Hi @sahsanu,

I was afraid that answer would arise.

Is there a known way to obtain this for money/a donation/rescuing kittens from tall trees?

Best,
Christian.

1 Like
#4

As far as I know, no, there is no way to obtain a certificate signed by X3. In the link I posted above they also offered money and the answer rermained no.

3 Likes
#5

Is it possible to manipulate the time for this "machines "in the field""? Do they use a time server you have control over? Because you could then announce a time where your old certificate would be valid.

1 Like
#6

Also, assuming you followed best practices and changed the certificate a month (or at least a few weeks) before expiry: why not switch back to the old certificate (which hasn't expired yet if done correctly) and use it to fix the damage?

2 Likes
#7

Nope.

If you look at the handy chart though- https://letsencrypt.org/certificates/ - Intermediate R3 chains up to "Root X1", just like Intermediate X3 did... so the root trust store is the same.

You could conceivably pin to the R3 chain AS A STOPGAP while you deploy a proper fix that removes the pinning.

1 Like
#8

The machines use *.pool.ntp.org, so even though that is a very good idea it won't work in this case.

#9

@jvanasco It is my understanding that the pinning process checked the whole chain - and not just parts of it.
I have, though, pointed my much more technically inclined colleagues to your answer for which I am very thankful!

The problem further seems to be that we cannot implement a stopgap measure on the devices as they currently do not pull any information (including said measures) from the server. We'd need to update the application (that process luckily still works), yet there's machines that need to be used "right after unpacking" and waiting for a background update might not be feasible for the actual user.