Stefan,

On 1/25/21 17:19, Stefan Mayr wrote:
Am 25.01.2021 um 19:04 schrieb Christopher Schultz:
All,

On 1/25/21 11:10, Christopher Schultz wrote:
All,

Off-topic, but I know there are plenty of Spring users on this list
who can probably help me figure this out.

Recently, Let's Encrypt switched from using their soon-to-be-expiring
intermediate certificate:

Owner:  CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co.
Serial number: a0141420000015385736a0b85eca708
Valid from: Thu Mar 17 12:40:46 EDT 2016 until: Wed Mar 17 12:40:46
EDT 2021

To this new one:

Owner: CN=R3, O=Let's Encrypt, C=US
Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co.
Serial number: 400175048314a4c8218c84a90c16cddf
Valid from: Wed Oct 07 15:21:40 EDT 2020 until: Wed Sep 29 15:21:40
EDT 2021

...

But why had it worked before, when cacerts didn't include the *previous*
intermediate certificate?


Because you usually don't need to add intermediate certificates to your
truststore. Your SSL-ified services presents his public certificate and
the certificate chain (all intermediates) to a client. The client
verifies the certificate chain you provided and checks the last
certificate against its truststore containing all root CAs.

I understand how certificate chains work.

I'm working with a Java version old enough not to have Let's Encrypt's certificates OR their cross-signer's present in the cacerts file.

So for your old and new certificate this should all work out if DST Root
CA X3 is in your cacerts file.

And it is not:

$ keytool -list -v -keystore ${JAVA_HOME}jre/lib/security/cacerts | grep 'DST Root'
[nothing]
$

For the next new cert you will have two options for the certificate
chain:
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
or for the complete view of chains: https://letsencrypt.org/certificates/

So for a future proof setup you should have ISRG Root X1 in your
truststore or keep an eye on the intermediate certificate you use.

Since I (evidently) finally got the custom trust store working, I will be doing exactly that: importing ISRG's Root X1 and also DST Root CA X3 for the next few months. (And ISRG Root X2 as well, for that matter.)

My guess for your current problem would be the following: your LDAPS
didn't update the chain and still provides the X3 instead of the R3
intermediate.

This is the current behavior of certbot. I am not specifically directing LE's choosing of the intermediate certificate so I get what they send to me. They are sending my server's cert signed by the R3 certificate, and (of course) sending the R3 certificate as the intermediate cert.

The old intermediate certificate is ignored and it now
only works when you add the intermediate certificate to your truststore.
Please verify which intermediate certificate is provided by your LDAPS

e.g. openssl s_client -connect ldaps.example.com:636 -showcerts

It's the R3 cert, just like I said in my initial post.

Had I initially installed the DST Root CA X3 certificate into my trust store (really cacerts, as it seems I have had a typo in my configuration for several years), there there would have been no problem. (Well, not until later this year when they switch to ISRG Root X2 if they don't include two intermediate certs in the chain they send to me.)

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to