Debian ECDSA chain issue

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.

  1. Convert pem to crt:
    openssl x509 -outform der -in 0000_chain.pem -out 0000_chain.crt
  2. Copy crt to /usr/share/ca-certificates/ or /usr/local/share/ca-certificates/
  3. update-ca-certificates - and failed..

I also tried dpkg-reconfigure ca-certificates - it doesn't see the copied crt

For step one try:

  1. Convert pem to crt:
    mv 0000_chain.pem 0000_chain.crt

I don't think Debian expects the crt file in der format.

1 Like

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.

1 Like

Not sure if Debian uses this, but I'd try:
update-ca-certificates

2 Likes

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?

3 Likes

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.

3 Likes

I might be wrong but as soon as I set the new E1 full-chain for my email and ldap servers they stopped working due to "unknown root certificate"

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

3 Likes

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

That's precisely what I talked about:

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

olcTLSCertificateFile: /path/to/my/certificate/fullchain.pem

So effectively using fullchain instead of cert.

(assuming an OpenLDAP server that uses OLC - your system might be different)

Same/Similar procedures apply for email, if that has the same error.

[@rg305 might want to split this to its own thread?]

3 Likes

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

3 Likes

All good, this now has its own thread. If you have any issues configuring this, just let us know. We're here to help :grinning:.

3 Likes

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:

  1. Create 3 separate ISRG1.crt, ISRG2.crt and E1.crt in pem-format.
  2. Copy them into /usr/local/share/ca-certificates/
  3. update-ca-certificates
2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.