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.
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.
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 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.
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?