Re: [OT] Spring Security LDAPS authenticator won't trust TLS cert
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: a014142015385736a0b85eca708 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
Re: [OT] Spring Security LDAPS authenticator won't trust TLS cert
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: a014142015385736a0b85eca708 >> 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. So for your old and new certificate this should all work out if DST Root CA X3 is in your cacerts file. 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. 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. 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 - Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Spring Security LDAPS authenticator won't trust TLS cert
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: a014142015385736a0b85eca708 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 We are using LE for our LDAPS server and our latest-issued certificate is signed by and includes the above ("R3") certificate in the server's certificate chain when contacted by a client. As soon as this switch occurred on Saturday, two of my dependent services stopped working. It took me quite a while to figure out the underlying issue, but I got one of them back up and running by simply adding the new R3 intermediate certificate to the trust store of a non-Java service (actually, it was Apache httpd mod_authz_ldap). That was fun tracking-down, but I digress. The other service is JasperReports Server, which uses Spring Security for authentication against our LDAPS database. It's running on Tomcat, and here is the important part (IMO) of the command-line of the running process: -Djavax.net.ssl.trustStrore=conf/truststore.jks -Djavax.net.ssl.trustStrorePassword=[the password] The "conf" directory refers to $CATALINA_BASE/conf. Dumping the existing conf/truststore.jks file reveals the contents: Alias name: letsencrypt Creation date: Dec 12, 2016 Entry type: trustedCertEntry 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: a014142015385736a0b85eca708 Valid from: Thu Mar 17 12:40:46 EDT 2016 until: Wed Mar 17 12:40:46 EDT 2021 Nice. So just add the new certificate to the trust store and restart the service, right? $ keytool -importcert -alias 'letsencrypt2020' -keystore conf/truststore.jks Enter keystore password: -BEGIN CERTIFICATE- MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7 gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel /xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0 LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8 S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg== -END CERTIFICATE- 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 Certificate fingerprints: MD5: 31:21:28:F5:A0:ED:7B:A5:4B:65:82:92:87:56:BA:83 SHA1: 48:50:4E:97:4C:0D:AC:5B:5C:D4:76:C8:20:22:74:B2:4C:8C:71:72 SHA256: 73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:92:5B:2A:77:1D:64:0A:26:F7:A4:54:22:4D:AD:3B Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: caIssuers accessLocation: URIName: http://apps.identrust.com/roots/dstrootcax3.p7c ] ] #2: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ : C4 A7 B1 A4 7B 2C 71 FA DB E1 4B 90 75 FF C4 15 .,q...K.u... 0010: 60 85 89 10 `... ] ] #3: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:0 ] #4
Re: [OT] Spring Security LDAPS authenticator won't trust TLS cert
Maybe try removing the old cert as its not expired yet? On 25/01/2021 16:10, Christopher Schultz wrote: Alias name: letsencrypt Creation date: Dec 12, 2016 Entry type: trustedCertEntry 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: a014142015385736a0b85eca708 Valid from: Thu Mar 17 12:40:46 EDT 2016 until: Wed Mar 17 12:40:46 EDT 2021
RE: [OT] Spring Security LDAPS authenticator won't trust TLS cert
Hi Chris, Are these typos for trustStrore (should be trustStore, yes?) from below from a copy/paste? > -Djavax.net.ssl.trustStrore=conf/truststore.jks > -Djavax.net.ssl.trustStrorePassword=[the password] I'm not a spring expert at all but everything else you mentioned looks right to me, that's the only thing that looked off. HTH - Jim -Original Message- From: Christopher Schultz Sent: Monday, January 25, 2021 11:11 AM To: Tomcat Users List Subject: [OT] Spring Security LDAPS authenticator won't trust TLS cert CAUTION EXTERNAL EMAIL: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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: a014142015385736a0b85eca708 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 We are using LE for our LDAPS server and our latest-issued certificate is signed by and includes the above ("R3") certificate in the server's certificate chain when contacted by a client. As soon as this switch occurred on Saturday, two of my dependent services stopped working. It took me quite a while to figure out the underlying issue, but I got one of them back up and running by simply adding the new R3 intermediate certificate to the trust store of a non-Java service (actually, it was Apache httpd mod_authz_ldap). That was fun tracking-down, but I digress. The other service is JasperReports Server, which uses Spring Security for authentication against our LDAPS database. It's running on Tomcat, and here is the important part (IMO) of the command-line of the running process: -Djavax.net.ssl.trustStrore=conf/truststore.jks -Djavax.net.ssl.trustStrorePassword=[the password] The "conf" directory refers to $CATALINA_BASE/conf. Dumping the existing conf/truststore.jks file reveals the contents: Alias name: letsencrypt Creation date: Dec 12, 2016 Entry type: trustedCertEntry 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: a014142015385736a0b85eca708 Valid from: Thu Mar 17 12:40:46 EDT 2016 until: Wed Mar 17 12:40:46 EDT 2021 Nice. So just add the new certificate to the trust store and restart the service, right? $ keytool -importcert -alias 'letsencrypt2020' -keystore conf/truststore.jks Enter keystore password: -BEGIN CERTIFICATE- MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7 gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel /xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0 LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8 S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg== -END CERTIFICATE- 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 Certificate fingerprints: MD5: 31:21:28:F5:A0:ED:7B:A5:4B:65:82:92:87:56:BA:83 SHA1: 48:50:4E:97:4C:0D:AC:5B:5C:D4:76:C8:20:22:74:B2:4C:8C:71:72 SHA256: 73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:9