As reported in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/TEDZOVX6S5W7BVX5PLMO6ASJHQYQUENE/ , external CA certificates are tracked for renewals by certmonger on fresh installs, and will be renewed/replaced with a self-signed CA certificate if certmonger decides it's close enough to the expiration time. This obviously shouldn't happen, and breaks the delegation chain for everything (particularly non-IPA clients) that only trusts the root CA.
Verified reproducible by installing a new F31 VM with freeipa-server-4.8.4-2.fc31 and running through the two step ipa-server-install --external-ca process. Among the certmonger requests:
Request ID '20200119025538': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=example.com CA,O=example.com subject: CN=example.com IPA CA,O=example.com expires: 2022-01-17 21:52:14 EST key usage: keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca" track: yes auto-renew: yes
After this occurs, it's not possible to convince IPA to sign any certificates properly, even after generating and installing a new externally-signed CA certificate -- the returned chains, certificate lifetimes, etc. all correspond to the self-signed certificate. Revoking it doesn't seem to matter, nor is there any readily apparent way to remove it.
I have confirmed that certmonger (or rather, the dogtag-ipa-ca-renew-agent renewal helper) is renewing externally-signed certs as self-signed.
dogtag-ipa-ca-renew-agent
@frenaud I think this may be a regression introduced in commit 49cf5ec. What do you think?
@ftweedal you probably spotted the culprit. The patch didn't take into account all the possible renewal paths (automatic for self-signed, automatic for ext signed, and switch from self to ext or the reverse). I need to take a closer look at the difference when we call the helper with RENEWAL_REUSE_CA_NAME or RENEWAL_CA_NAME.
Okay, I'm confused -- what's the intent behind tracking an externally signed CA for renewal? Even if the renewal helper is supposed to do nothing in that case, it's surprising to see certmonger paying attention at all... If it's for logging expiration warnings or something of that nature, why are auto-renew and/or the renewal helper set in this case?
@rwf the purpose is two fold:
First, yes, we track the cert so that we can log expiration warnings etc.
Second (and more important), the renewal helper checks the LDAP ca_renewal subtree for a new CA certificate. If it has appeared (i.e. because you ran ipa-cacert-manage renew --external-cert-file new-ca-cert.pem on another CA server), the renewal helper will pick it up and install it. This is how new CA and system certificates get automatically distributed among the CA replicas.
ca_renewal
ipa-cacert-manage renew --external-cert-file new-ca-cert.pem
Erm, that raises even more questions... Does ipa-certupdate not do that? What if the external CA is renewed/replaced on another CA server well in advance of its expiration?
@rwf
Does ipa-certupdate not do that?
No. ipa-certupdate is primarily about propagating trusted certs from the IPA LDAP trust store to system certificate databases and trust stores. Well on second thought, it may be that ipa-certupdate does install the new CA certificate in the Dogtag NSSDB, but if so, that is incidental and is not the "normal" way to install a new IPA CA certificate (or other Dogtag system certificates) in the Dogtag NSSDB.
ipa-certupdate
What if the external CA is renewed/replaced on another CA server well in advance of its expiration?
If you do nothing, the other CAs will continue to operate normally with their obsolete-but-not-yet-expired signing certificate. When the expiry approaches, certmonger will attempt to "renew" and the request helper will retrieve the new CA certificate from LDAP.
Alternatively, you can trigger the installation of the new CA certificate on the other CA replicas by running getcert resubmit -i $REQUEST_ID on each one.
getcert resubmit -i $REQUEST_ID
Got there by assumption just now, but verified that there's no mention of that at https://www.freeipa.org/page/Howto/CA_Certificate_Renewal -- it specifically says that ipa-cacert-manage renew is enough.
There's an awful lot of reliance on "hope somebody/something runs this before expiration" going on here... I've already had to nuke the replicas to try to contain the mess the self-signed cert has created this time around, so I guess I can skip this part, but still. Ugh.
PR: https://github.com/freeipa/freeipa/pull/4148
master:
Metadata Update from @ftweedal: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @ftweedal: - Issue status updated to: Open (was: Closed)
Metadata Update from @ftweedal: - Issue assigned to ftweedal
ipa-4-8:
ipa-4-7:
ipa-4-6: * c30af44 Do not renew externally-signed CA as self-signed
Login to comment on this ticket.