I'm trying to establish connection to the https://www.stark-research.net domain. Web browser is giving correct certs chain with new ISRG Root X1 cert (SN: 008210cfb0d240e3594463e0bb63828b00).
The long chain that @Osiris mentions is served automatically by web servers to all clients, regardless of whether a particular client benefits from it (like old Android), ignores it (like most web browsers), or is harmed by it (like older OpenSSL clients and some older web browsers). Its motivation is to provide compatibility with older Android clients, but an individual web server doesn't actually know whether a particular client will want the long chain or not, so it normally serves that chain to all clients.
The web browser is probably receiving the same chain from the server, but not displaying it to you. Most web browsers (unlike openssl s_client) don't actually show exactly what chain was sent by the server, but rather show whatever valid chain the web browser was able to build based on its own root store and cached intermediate certificates (including those from other sites).
Client operating systems (and many tools) build there own preferred chain based on what they see from the server. So the server can present one thing and the client can choose to build a trusted path however it wants to. On Windows in IE, Edge, Chrome (current version) this specifically works using the Windows trust store and the windows chain building engine, which if it's up to date will build Leaf > R3 > ISRG Root X1 regardless of which LE chain is presented by the server.
This is because Windows doesn't trust the expired DST Root CA X3 (if it can find something else), and will try to build the path to ISRG Root X1 (Self signed) instead, which it should be able to do if the OS trust store is up to date. If you ever see the DST Root CA X3 chain in the Windows certificate viewer it's either because the machine you are on doesn't have ISRG Root X1 installed or the chain presented is still using the old R3 (which is increasingly unlikely, but common on Window servers that haven't been rebooted for a while)
Asides from trying to understand why the chain is shown one way or the other, is there a specific problem you are trying to solve?
Thanks for response. My goal is to build simple integration to the stark-research.net. Anyway when I'm trying to establish secure HTTP connection, it is failing with error:
validating certificate chain
looking in datastore for certificate with DN CN=R3, O=Let's Encrypt, C=US
match found
looking in datastore for certificate with DN CN=ISRG Root X1, O=Internet Security Research Group, C=US
CA certificate with correct DN, but fingerprint '0CD2 F9E0 DA17 73E9 ED86 4DA5 E370 E74E' found. Continuing search.
No match found
CA certificate with issuer CN=DST Root CA X3, O=Digital Signature Trust Co. and serial number 4001 7721 37D4 E942 B8EE 76AA 3C64 0AB7 is not a trusted certificate
server chain validation failed: com.tibco.security.AXSecurityException: CA certificate with issuer CN=DST Root CA X3, O=Digital Signature Trust Co. and serial number 4001 7721 37D4 E942 B8EE 76AA 3C64 0AB7 is not a trusted certificate
Certs in my trust store:
adding as trusted cert:
Subject: CN=www.stark-research.net
Issuer: CN=R3, O=Let's Encrypt, C=US
Algorithm: RSA; Serial number: 0x40ca91462c2ac5be1b127806354c07f4408
Valid from Wed Sep 15 10:21:27 CEST 2021 until Tue Dec 14 09:21:26 CET 2021
adding as trusted cert:
Subject: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Algorithm: RSA; Serial number: 0x8210cfb0d240e3594463e0bb63828b00
Valid from Thu Jun 04 13:04:38 CEST 2015 until Mon Jun 04 13:04:38 CEST 2035
adding as trusted cert:
Subject: CN=R3, O=Let's Encrypt, C=US
Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US
Algorithm: RSA; Serial number: 0x912b084acf0c18a753f6d62e25a75f5a
Valid from Fri Sep 04 02:00:00 CEST 2020 until Mon Sep 15 18:00:00 CEST 2025
Ok, you need to find out how to update the list of trusted CA certificates that Tibco uses. I'd suggest contacting Tibco support and they can probably easily tell you. For Java based stuff this often involves importing the root certificate into your key store using keytool, but there may also be a UI for that in Tibco as it's a pretty common thing to need to do.
You shouldn't add end leaf certificates nor intermediate certificates into your root trust store: only the ISRG Root X1 should be added.
Also, could you perhaps elaborate on what kind of client is being used? Because that output doesn't look like OpenSSL to me. It's probably the chain building logic of the client used that's giving you trouble.
Thanks! I tried to upload only ISRG Root X1 cert (not the full chain). Anyway it failed this way:
validating certificate chain
looking in datastore for certificate with DN CN=R3, O=Let's Encrypt, C=US
No match found
CA certificate with issuer CN=ISRG Root X1, O=Internet Security Research Group, C=US and serial number 0000 912B 084A CF0C 18A7 53F6 D62E 25A7 5F5A is not a trusted certificate
server chain validation failed: com.tibco.security.AXSecurityException: CA certificate with issuer CN=ISRG Root X1, O=Internet Security Research Group, C=US and serial number 0000 912B 084A CF0C 18A7 53F6 D62E 25A7 5F5A is not a trusted certificate
I'm using TIBCO tool to implement integration. it is based on Java. I used openSSL and Portecle to double check and examine SSL connection and both are giving same issue like I got on TIBCO.
When I tried OpenSSL everything worked like a charm. Unfortunately I'm not familiar with Java so I can't help you with that. Maybe someone else knows more about this stuff.
Please read the news post I've linked at the top of this thread: this is intended behaviour with the default chain.
If you wish to change that and lose compatibility with Android devices older than 7.1.1, you have the option to change to the alternative certificate chain.
Sorry. It is not clear to me. I'm not working with Android devices. I need to create truststore.jks to establish HTTP connection to the stark-research.net. When I uploaded new chain to the truststore, then it is failing to expect DST Root CA X3. When I'm doing in opposite side, adding old chain - connection is failing as DST Root CA X3 expired. Blog is not giving anything useful to me.
I don't understand this part: how is DST Root CA X3 in the picture when using the new (alternative) chain? With that chain there is no DST Root CA X3 to speak of.
It is expecting DST Root CA X3 because even openssl is showing certs ONLY in the alternative way. Only webbrowser is showing new chain. OpenSSL and Portecle are showing ONLY old chain. Trust store with old chain is failing as X3 is not valid anymore (expired).