Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I can't seem to reach your LDAP server on the default TLS port 636 even though your hostname resolves to a public IP. Is there a selective firewall in place? Regardless, can you post the first 10'ish lines of output after running openssl s_client -connect ldap.ligo.uwm.edu:636? You may also want to post the portion of the LDAP server config that points to your certificate/key/chain files and mention what LDAP server you're using.
Yes, the LDAP is a replica from off-site, hence the public IP, but can only be queried on-site, for security purposes. We have reliant services that cannot do an authenticated bind.
The ability to connect to the LDAP is not the issue I am trying to address right now, but for the record:
$ openssl s_client ldap.ligo.uwm.edu:636
CONNECTED(00000003)
depth=2 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=2 O = Digital Signature Trust Co., CN = DST Root CA X3
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=10:certificate has expired
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=0 CN = ldap.ligo.uwm.edu
notAfter=Nov 8 12:00:14 2021 GMT
verify return:1
---
Certificate chain
0 s:CN = ldap.ligo.uwm.edu
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
2 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFKjCCBBKgAwIBAgISBI++ShaRa9EC4ASqU6luib+rMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA4MTAxMjAwMTZaFw0yMTExMDgxMjAwMTRaMBwxGjAYBgNVBAMT
EWxkYXAubGlnby51d20uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAu8ln7suO/JvSGtXhuXBRSHBQse70eOiceEheuCzS4bhkEUGlhsAWT1/714vO
dy1eZpzob9r/c2tzaUbFnhywOjFubMiBCuDUtNPuyekk/DKCXwFiSubJcROsQNu0
Uh866dCmdmI44v+sH0nFI4Y4RLzIx+TZr0o6pTjYXNIcSbu6PHnXp76ZbcsWcV6S
n4mSb2aML2vniAc0Oy33ETywDUDzHeXeoBs8qtjro84gOcPkzZjhfSh2yve8FJcU
KkeZ1OgZdAjY8TANzJs5APRWkXSSlM7C9eBU4RTFfpQGwjt0DsB5sif6Ds5EJ1xo
HLY6rPs61ApcawgBiWdZyp5+jQIDAQABo4ICTjCCAkowDgYDVR0PAQH/BAQDAgWg
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBTzGmd5jVUG7LV2ccjxP9Zoy0zGEDAfBgNVHSMEGDAWgBQULrMXt1hW
y65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6
Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iu
b3JnLzAcBgNVHREEFTATghFsZGFwLmxpZ28udXdtLmVkdTBMBgNVHSAERTBDMAgG
BmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3Bz
LmxldHNlbmNyeXB0Lm9yZzCCAQYGCisGAQQB1nkCBAIEgfcEgfQA8gB3AJQgvB6O
1Y1siHMfgosiLA3R2k1ebE+UPWHbTi9YTaLCAAABezAmN3sAAAQDAEgwRgIhAM3k
IkxZtWDBMRyG+joX0H+7JxncZ2lv6tfpx/Do9OdAAiEAmsEZDpEqDqXjOQF/CXs3
o5KWmaU8oajWbMQWsVYPuxgAdwD2XJQv0XcwIhRUGAgwlFaO400TGTO/3wwvIAvM
TvFk4wAAAXswJjdrAAAEAwBIMEYCIQD8pOn6W0mImeyWK7k8SYBMcJNtfxDCH69D
amP+88kjNAIhAOCqmeqFeDojxmuKTa+jYyfdCejxUURf18AJvil4K0jmMA0GCSqG
SIb3DQEBCwUAA4IBAQBiFmteK+IBb9/RyWITPekKJvNnhwwp6IlGk0oTQHwrGm0N
YmT/A1OOm0e0uNavrDRSec4XqYlZYGJ25ESZKE5p29UB1ZWeYGZcNy9zS3DIsFXR
pbiduzGFh9JN51iCSNHIHErYeX1T6ebi6Qe9YXJrbu5NhQylcNJ7kxrrrnqVmf3s
qO+utpIhhKuo/R3RnTUck1Un639ga3phoU6bjlEGB3Tm2wNrAzTUKgM3Ma1oqyqu
Ha94TAlvJHX+fQeFxx7rPw6GWITc0ItSXLzFskV1kxYezHM7HAFKa91P3/20uZST
hhaKCSFd/pOKPdj+jTEGFNJfpnKdI9RT8MRWodM0
-----END CERTIFICATE-----
subject=CN = ldap.ligo.uwm.edu
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3816 bytes and written 445 bytes
Verification error: certificate has expired
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 700CD13ED3DDB9303BE4514E7D450579B1376FCA5124184B89A79B010390C873
Session-ID-ctx:
Master-Key: 645D1E8BDA720ACBC9A0847877730F84FE1B08AB73B50BD5ADF81757AE623A9BB397551023C48E58706D999ED9882ACD
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1633445277
Timeout : 7200 (sec)
Verify return code: 10 (certificate has expired)
Extended master secret: yes
---
and
# grep TLS /etc/ldap/slapd.d/cn\=config.ldif
olcTLSCertificateFile:: L2V0Yy9sZGFwL3g1MDktY2VydHMvbGRhcC5saWdvLnV3bS5lZHVf
olcTLSCertificateKeyFile:: L2V0Yy9sZGFwL3g1MDktY2VydHMvbGRhcC5saWdvLnV3bS5lZ
olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt
root@ldap:/etc/ldap# timed out waiting for input: auto-logout
There is no web server on this machine, so port 443 is not the one we want, 636 is. I posted the entire openssl s_client output in another reply in this thread.
Then how about showing right up until the first cert is shown [not just the very top part]: openssl s_client -connect ldap.ligo.uwm.edu:636 -servername ldap.ligo.uwm.edu
Sorry, the full output is there now, the forum cut off my email in mid quote, so I edited it in the web client.
I will try removing the expired X3 cert if I can figure out how.
That is a problem!
It has all the wrong chain.
A chain that hasn't been provided since May 2021.
Which means the process includes some hard-coded chain certs - not good.
The leaf cert is up-to-date, so that part is correct.
Thanks for the insight, Rudy, but not being all that familiar with this process, I guess I'm still confused. Maybe someone can tell me where I am misunderstanding what is going on. I understand the process to be the following:
A CSR is created on my server. It contains basically an unsigned cert. A private key is generated to go with it.
The unsigned cert is sent off to Let's Encrypt to be signed and a signed cert is returned to my server.
In my case, my cert is signed by the Let's Encrypt intermediate R3 CA.
According to openssl, the R3 certificate that signed my certificate was in turn signed by DST Root X3 CA, which signed it with an expired root certificate.
According to Chain of Trust - Let's Encrypt, the R3 certificate that signed my certificate should have been signed by the ISRG Root X1 CA, presumably with an unexpired root certificate.
My confusion comes from not understanding how what is happening on my server can affect any part of the process after the CSR has occurred. This cert was signed on Aug, 10, 2021. How was it signed by a chain that wasn't available after May 2021?
Only because that version of R3 being served is many months old - and not the one being provided to anyone by LE (since May 2021).
If you check any of the chain.pem files provided with any of your certs (since May 2021), you will see that the R3 cert was signed by "ISRG Root X1" (a root CA)
Therein lies the recent problem. The cross-signing (when one ROOT is signed by another ROOT) cert has recently expired ("DST Root CA X3"). So some devices fail to validate the leaf because one of the two roots in the path has expired.
I would check the scripts that manipulate/install the cert into your system (after LE has issued them to your server - via certbot).
Certificates do not sign anything, keypairs (which are contained in certificates) do. There are multiple certificates all representing the "R3" keypair. All of these certificates are technically valid issuers for your certificate, but that doesn't mean that they're all identical (they have different issuers and validity periods for example). The ACME server returns the "current" R3 certificate, but your systems may have ignored that and used another R3 certificate.
More nuclear physics? - LOL
Explain it so that every reader can understand you.
Who knows... some might be 11.5 years old (average age of a 5th grader).
Given that this user already had the basic concepts of CA and the signing process, I didn't feel like my explanation was overly complicated. The concept of a "key" is certainly fairly well understood - it's a secret thing that locks or unlocks something (in this case the magic of "signing", which can be thought of like a signature on paper, where the "key" is my personal style). Asymmetric keys (such as those used here) are more complicated, sure, but that's why I didn't mention that at all. I could have made this a lot longer to go into a bit more detail, but that would have blown up things very quickly.
I honestly don't know how to put this in a more basic form. If we don't make the differentiation between keypair and certificate, you can't clear up the confusion users experience ("How can I have the wrong R3, if R3 signed my certificate"). The chain of trust page on Let's Encrypts website also makes this key - certificate differentiation .
Does that sound "well understood"?
I'm hearing/feeling a basic level of understanding.
[not to ./bash on anyone... but the response should not far exceed the questioners comprehension level about the topic or introduce anything that doesn't lineup with common thoughts or assumptions (unless those are totally wrong - then all bets are off and one has to do what one has to do to keep the sanity and stop the chaos)]
That said...
That is a very valid point and there should be a document that can explain it - simply and maybe with pictures and anecdotes too - so that all can understand how certs are certs.
For those that want to, or need to, fully understand it.
But most people don't really care "how" anything; And frankly the less they have to, the better we have all done our jobs. Because that means they can fill their heads with other things... things we don't fully understand - LOL
I mean who, outside of those that make them, really needs to know "how" a microwave heats food?!?! [right?]
My intention was not to give a full introduction into applied crypto, but rather to try and give a hint where the current thinking may be wrong. I believe this to be better than completly ignoring the users misunderstanding, even if it wasn't that helpful in the end. Just telling the user "use the other cert" may solve their immediate problem, but they probably will have learnt nothing along the way. Trying to point users into the direction where they got it wrong might change this - or it might not, in which case: No harm done, maybe it will help someone else one day.
This is almost 100% correct and far better than what I usually hear from users, so yes. This statement shows a pretty good understanding of the basic concepts. That's also what motivated me to point out that there's a highly important difference between "the cert" and "the key". I do not expect users to know the details of the math involved behind RSA or DSA - in fact, they usually don't need to bother with the existence of these algorithms at all.
Then we read (pronounced "red" - don't ask me why) that line 1 completely differently.
Like I hear it chronologically (left to right) and all too literally I suppose:
A. Generate CSR (which is basically an unsigned cert)
[this sounds like they understand CSR]
B. Generate a private key to "go" with it.
[but then this sounds way out-of-order and/or that the key will also be sent along with the CSR]
So 50% right means to me they do have an idea but some things are still fuzzy.
Yes, sorry, I was sloppy with language. One uses the private key to sign and the "public" key in the certificate to verify the signature. I am trying to parse this statement:
"The ACME server returns the "current" R3 certificate, but your systems may have ignored that and used another R3 certificate."
The CSR for my certificate is not signed on my system, is it? So how does what version of the R3 certificate I have on my system have anything to do with the signature? Now, for verifying the signature, I can understand that openssl might grab the system bundle and check against it and the system bundle might be out of date. However, I have checked from various systems and get the same result from all of them, so either all of the systems I have access to have outdated chains of trust at the system level or, more likely, the R3 cert that signed my cert was really signed by X3, no?
