Can not connect using ISRG root X1

Issuance Tech
1

Hello I use DST Root CA X3 for secure communication of my IOT device... which is valid untill 30.09.2021. Since lets encrypt is switching to new Root ISRG Root X1 which is valid untill 2035.. But i am unable to connect Using this new Root...My question is, is it because i still see DST root CA X3 as main root in my default certifcate chain... My cert chain is like this...DST root CA X3 ->ISRG root X1 ->R3 ->end cert(leaf)... my question is when will i be able to see default chain like this ISRG Root X1 -> R3 ->end cert (leaf) will this change after 30th of september next month??

Kind Answers will be highly appreciated

2 Likes
2

If you configure your client to request the alternate chain (e.g. certbot's --preferred-chain option, or uacme's --alternate option) which is rooted at ISRG Root X1, then you will receive the "short chain" which is just Subscriber Cert <-- R3 <-- ISRG Root X1 (self-signed).

You can see the full set of chains we offer on our certificate hierarchy page: Chain of Trust - Let's Encrypt

4 Likes
3

@aarongable’s advice is spot on, but I’d like to add the following:

You should check your ssl setup with qualsys or a similar server test to ensure you are serving the intended chain.

Web browsers and other SSL clients may not show the actual chain used in the connection, due to caching and some inherent qualities of SSL certificates. It is possible your server is properly configured for the future, but your client is just showing the wrong chain

3 Likes
4

Per @jvanasco's excellent suggestion, I'd like to mention the following fast and easy tool:

https://certlogik.com/ssl-checker/

It's not a full-spectrum SSL test like qualys, but it runs worlds faster if you only want the basics (like the chain actually being served).

2 Likes
5

Please have a look at this ..This is my certificate chain i see with qualsys. Which is new default long chain... it still shows an ISRG Root X1 which not self signed instead signed by DST Root CA X3
https://www.ssllabs.com/ssltest/analyze.html?d=letsencrypt.org&s=138.197.214.0&latest

6

The site uses a really outdated trust store though, which for example doesn't include ISRG Root X1.

So it's information about whether some CA chain is trusted should not really be relied upon.

2 Likes
7

With this tool i see same cert chain . Which is new default long chain... it still shows an ISRG Root X1 which is not self signed instead signed by DST Root CA X3

8

I am using an LTE module BG95M3 which will run in a remote area any where in the world i can not use the whole certificate chain because my sub cert changes every three months.. so i only use Root cert to validate my cert chain because root cert has longer validity and i do not need to update my firmware all the time... The problem is my module works fine with old root DST Root CA X3 but it is not accepting new self signed ISRG Root X1.. I thought it is because i do not see alternative chain which is self signed ISRG Root X1 issued....Instead i see new default chain which has ISRG Root X1 signed by the old root DST Root CA X3... AND my Chain looks like this

DST root CA X3 ->ISRG root X1 ->R3 ->sub cert

i have tested with above mentioned qualsys and certlogik ...i still get the new default chain...

I hope i have given a clear view of the situation now

9

I'm afraid the situation has gotten less clear.

Then you are not serving the whole chain?

So... you only serve the leaf and the root cert?

When you look at the complete chain in SSL LABS (Qualys), does it show "extra download"?

2 Likes
10

I only really use that tool for viewing the transmitted certificates since the trust store on someone else's machine is of little consequence.

2 Likes
11

@danny1, (Why) are you hesitant with providing an FQDN that is having this issue?
It is extremely more difficult to help anyone this way.

2 Likes
12

@griffin and @Nummer378
I think you both may be right:

TRUE.

Also TRUE; any conclusion about the provided certs, or evaluation thereof, might be inaccurate when based on an older trust store. And should NOT be used for this sole purpose.

2 Likes
13

certlogik_trust_store
certlogik_trust_store922×269 7.78 KB

3 Likes
14

Ah.

:sweat_smile:

I stand corrected. I never really pay attention to that line. I have updated my previous post accordingly.

The problem I've had with many such tools is that they are usually either really slow (ssl labs test) or really confusing to interpret based on assumed trust stores.

2 Likes
15

Here are several more that appear to work well:

https://decoder.link/sslchecker/

https://www.sslshopper.com/ssl-checker.html

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

https://ssltools.godaddy.com/views/certChecker

2 Likes
16

Yes i am not serving the whole chain

17

I only serve root cert not leaf

18

i am not hesitant..when i have explained the situation why do you need FQDN? on qual sys link u can check its for mine too only leaf cert is different everything else is same ...

19

And many years of experience has taught me that 4 eyes are better than 2.
6 are better than 4.
8 are better than 6.
...
The more people look into this the more likely someone will spot the problem (that much faster).
I mean, we are agreed, there IS a problem - right?
OK, so what is it?

1 Like
20

What is the error message shown/thrown?

1 Like