OpenSSL CA Root doesn't chain to ISRG Root X1

My domain is:

I ran this command:
openssl s_client -showcerts -verify 10 -connect < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/) {a++}; print >out}'

It produced this output:
verify depth is 10
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
notAfter=Sep 30 18:14:03 2024 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
notAfter=Sep 15 16:00:00 2025 GMT
verify return:1
depth=0 CN =
notAfter=Jan 2 17:16:13 2022 GMT
verify return:1

My web server is openldap 2.4:

The operating system my web server runs on is CentOS 7

I can login root in my machine

certbot 1.11
OpenSSL 1.0.2k-fips 26 Jan 2017

My servers can´t auth against my Ldap server,seems it´s invalid

Follow this guide.

OpenSSL 1.0.2 Chain Guide


unfortunately i don´t have any access to clients servers, just the ldap server. Is there any workaround in this situation?

Unfortunately I do not know, only possible way I know is to update OpenSSL. You need to tell your client that they need to update their Server.

@gustavo You should be able to use the -trusted_first option in your openssl command to validate correctly. That was the Workaround 2 in the doc that @abdul201588 provided.

I could not show you the result of -trusted_first because your client has already changed their server and is no longer sending any chain - just a single leaf cert. Which will not validate.

Certificate chain
 0 s:/
   i:/C=US/O=Let's Encrypt/CN=R3

I am using same openssl as you - I am testing from AWS Linux 2 EC2.

Edit: This is the command that should work with that original chain:

 openssl s_client -showcerts -verify 10 -connect -trusted_first

Please show:

openssl s_client -connect | head

[much simpler and clearer output]

Yes, but, also needs -trusted_first to validate the 'long chain'

Don't ask me how, but if you configure the LDAP server to send just the R3-signed-by-ISRG Root X1 intermediate, OpenSSL 1.0.2 should connect fine, assuming the client has ISRG Root X1 in their root store. You'd lose Android pre-7.1.1 compatibility, but I'm assuming that's fine for a LDAP server.

If the clients don't have ISRG Root X1 in their root store, there's nothing you can do anyway.


I don't want the output altered - so, no thanks.
I'd rather see what he gets RAW.


Thank you guys, already solved the issue, as my clients are trying to issue ISRG in X3, I generated another certificate in other entity i used, now I´m able to connect the clients and update the trusted store.

1 Like

? ? ? ?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.