Let's Encrypt Transitioned to ISRG's Root
Sunday, January 10. 2021
My previous post @ Let's Encrypt Transitioning to ISRG's Root.
Let's Encrypt's announcement: Standing on Our Own Two Feet also note their support plan for old Android phones: Extending Android Device Compatibility for Let's Encrypt Certificates to maintain their IdenTrust root as an alternative source.
To put it short, plans made back in 2019 got refined and went to execution. The certificates issued by Let's E have their own root CA certificate and are not depending on a partner organization's root.
I'm getting certs from Let's E, why should I care?
If you're lucky, no need to.
If you're like me, stuff stops working.
An example: my OpenLDAP slapd
is configured to serve LDAPS (that's TLS-wrapped LDAP) from TCP/636 with a Let's E cert I'm getting from them every 60 days. Last week I did run the update and my recent cert update was issued by their new R3 intermediate server, as X3 having been phased out.
To state the obvious, lot of stuff in Linux depend on ability to access users. Now that it was gone, the previously mentioned "lot of stuff" ceased to function.
The exact message I managed to dig out with slapd -d 3
was:
TLS trace: SSL_accept:TLSv1.3 early data
TLS trace: SSL_accept:error in TLSv1.3 early data
5ff9a0ec connection_get(23): got connid=1008
5ff9a0ec connection_read(23): checking for input on id=1008
TLS trace: SSL3 alert read:fatal:unknown CA
TLS trace: SSL_accept:error in error
TLS: can't accept: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca.
5ff9a0ec connection_read(23): TLS accept failure error=-1 id=1008, closing
Note: fatal:unknown CA
Ok, my stuff got broken, what now?
Luckily the fix is easy, go get the new R3 cert from https://letsencrypt.org/certs/lets-encrypt-r3.pem. To see all of their certs in Let's E chain-of-trust, go to https://letsencrypt.org/certificates/
When targeting specifically OpenLDAP and slapd
, I went to /etc/openldap/certs/
and symlinked lets-encrypt-r3.pem
from /etc/pki/tls/certs/
which is the standard Fedora/CentOS/RedHat location for certificate PEM-files.
After downloading the cert, next thing was to get the hash of the downloaded R3-cert:
# openssl x509 -hash -noout -in /etc/pki/tls/certs/lets-encrypt-r3.pem
Which outputted the result of (your result must be identical to this):
8d33f237
This hash needs to point to the actual PEM-file, symlink:
# ln -s /etc/pki/tls/certs/lets-encrypt-r3.pem 8d33f237.0
That should be the fix. Next systemctl restart slapd
and observe functioning OpenLDAP-server.
After any changes to my LDAP-configuration, I'll verify the result with a query similar what my Linux system would do with a direct LDAP-search of:
$ ldapsearch -H "ldaps://my.ldap.server.example.com/" -x \
-b ou=People,dc=example,dc=com \
"(cn=Jari Turkia)"
and system wrapper for above:
$ getent passwd jatu
Confirmed as working!
Done.
Final thoughts
I and everybody else had over an year to prepare for this. Did I? Nope. Had other more "important" things to do instead. Fail!