Has anyone got experience in installing the new E1 chain in Debian/Ubuntu's system trusted CA repositories?
No problem on Centos nor Archlinux, but here in Debian I stucked.
Convert pem to crt:
openssl x509 -outform der -in 0000_chain.pem -out 0000_chain.crt
Copy crt to /usr/share/ca-certificates/ or /usr/local/share/ca-certificates/
update-ca-certificates - and failed..
I also tried dpkg-reconfigure ca-certificates - it doesn't see the copied crt
Thank you very much, while updating the store it occurred the same errors but at least openssl s_client -connect ... succeed. There some issues concerning the connection ports but it's not the scope of this topic.
The chain files provided by most ACME clients contain intermediate certificates. Why are you trying to add intermediates to the system trust store in the first place?
You shouldn't have to - E1 is an intermediate certificate, not a Root CA you "need" to trust.
If anything, you may want to install ISRG Root X2 into your trusted CA repository, but until ISRG Root X2 will be included there by default (and then probably a while longer), it benefits from a cross-sign from ISRG Root X1, which should already be in your trust store.
The current E1 chain builds up to ISRG Root X1, identical to the current alternate RSA-chain.
If it works with the intermediates in the trust store, but not without, this is an indication that the email/ldap servers are misconfigured and not sending the intermediates (which they should do).
Sorry, maybe I have misconfigured something in this Debian, it's possible. The weird thing: when I provide openssl s_client -connect europe6.acvan.net:636 (to one on my ldaps) here on Debian it says:
CONNECTED(00000003)
depth=0 CN = acvan.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = acvan.net
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = acvan.net
verify return:1
---
Certificate chain
0 s:CN = acvan.net
i:C = US, O = Let's Encrypt, CN = E1
---
Server certificate
-----BEGIN CERTIFICATE-----
Verify return code: 21 (unable to verify the first certificate)
however from any other host the same makes no errors. Really, I don't understand
This server is only sending the leaf certificate, but not the required intermediate certificates.
This means that clients now have to fetch these certificates themselves, elsewhere. Some clients cache known intermediates, some load them via AIA, some use completly different protocols to load them and others (like OpenSSL) won't do any of this. This is why it won't work on some clients.
The correct fix for this issue is to configure the LDAP server to serve the intermediates, together with the leaf. How to do this depends on your exact LDAP configuration (which I can't guess), but it usually boils down to something like this:
Changing olcTLSCertificateFile: /path/to/my/certificate/cert.pem to
Thank you, Max, that's very kind of you.
On the other hand, the results of openssl s_client -connect from the other hosts to that Europe's ldap are successful. That means that I somehow misconfigured this Debian's CA store. On Centos and Arch I just copied 0000_chain.pem into trust anchors and update-ca-certificates, that's all.
I must read your and the other people's replied and reflect a little bit
Finally, with kind assistance of the nice people in this community, the solution for Debian has been found.
My Debian's CA store didn't consist ISRG Root X1 root neither, of course, ISRG X2 nor E1 certificates. And also I found that it doesn't accept chained certificates, like 0000_chain.pem. So:
Create 3 separate ISRG1.crt, ISRG2.crt and E1.crt in pem-format.