OpenSSL CA Root doesn't chain to ISRG Root X1

Help
1

My domain is: ldap-aws-us-east-1a.dc.pkds.it

I ran this command:
openssl s_client -showcerts -verify 10 -connect ldap-aws-us-east-1a.dc.pkds.it:636 < /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 = ldap-aws-us-east-1a.dc.pkds.it
notAfter=Jan 2 17:16:13 2022 GMT
verify return:1
DONE

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

2

Follow this guide.

OpenSSL 1.0.2 Chain Guide

2 Likes
3

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

4

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.

5

@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:/CN=ldap-aws-us-east-1a.dc.pkds.it
   i:/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----

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 ldap-aws-us-east-1a.dc.pkds.it:636 -trusted_first
6

Please show:

openssl s_client -connect ldap-aws-us-east-1a.dc.pkds.it:636 | head

[much simpler and clearer output]

7

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

8

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.

2 Likes
9

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

2 Likes
10

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 sslforfree.com, now I´m able to connect the clients and update the trusted store.

1 Like
11

? ? ? ?

12

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