freeipa

#9074 `ipa-server-certinstall` no longer works with letsencrypt-issued certificates from certbot
Closed: invalid by rcritten. Opened by farnz.

Closed: invalid
Reopen Issue

When certbot gets me a LetsEncrypt certificate, the CA chain includes an expired CA certificate, CN=DST Root CA X3,O=Digital Signature Trust Co.

In order to use ipa-server-certinstall to have a LetsEncrypt certificate for the Web component (LDAP can be from the internal CA in my setup, but I want the web server to use a global certificate), I had to do two separate nasty hacks:

  1. Edit ipaserver/install/ipa_cacert_manage.py so that (line 438 or so) does not attempt to check for the validity of the CA certificate. This let me use ipa-cacert-manage to install the expired CA certificate, and I do not expect to need to repeat this.
  2. Edit ipaserver/install/installutils.py so that (line 939 or so) does not validate the CA certificate:
        # verify CA validity and pathlen. The trust_chain list is in reverse
        # order. trust_chain[1] is the first intermediate CA cert and must
        # have pathlen >= 0.
        for minpathlen, nickname in enumerate(trust_chain[1:], start=0):
            try:
                nssdb.verify_ca_cert_validity(nickname, minpathlen)
            except ValueError as e:
                pass
                #raise ScriptError(
                    #"CA certificate %s in %s is not valid: %s" %
                    #(subject, ", ".join(cert_files), e))

I'm using Fedora 35, with FreeIPA version freeipa-server-4.9.8-1.fc35.x86_64

I would like to be able to use ipa-server-certinstall to install LetsEncrypt certificates without the hack:
ipa-server-certinstall -w privkey.pem combined.pem

You should open a bug against certbot. IPA is doing you a favor in not allowing an invalid chain to be installed.

You should open a bug against certbot. IPA is doing you a favor in not allowing an invalid chain to be installed.

IPA is breaking things, because the chain is perfectly valid. See https://community.letsencrypt.org/t/production-chain-changes/150739 for an explanation - what's going on is a valid chain to the ISRG Root X1, but there's a cross-sign from DST Root CA X3.

I have imported the ISRG Root X1 as a CA using ipa-cacert-manage install; for maximum compatibility, the chain uses a cross-signed ISRG Root X1 certificate that has been signed by the expired DST Root CA X3 as well as containing a self-signed version of ISRG Root X1. Modern setups recognise that ISRG Root X1 is a valid CA, verify the signatures to that CA in the chain, and accept that the cert is valid. Older setups don't know about ISRG Root X1 as a CA, but do know about DST Root CA X3; the extra entry in the chain permits those clients to use their knowledge of DST Root CA X3 to validate the signature.

As proof, I've simply bypassed IPA's protections against installing this, and https://extserv.farnz.org.uk/ipa/ui/ has a perfectly valid chain that Firefox accepts.

You need the Let's Encrypt R3 certificate in the chain.

Firefox already trusts the LE chain which is why it works. IPA loads all the certificates provided and on their own then validates them. Because R3 is missing the validation failed.

Metadata Update from @rcritten:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.