On May 30, 2020, the AddTrust CA expired as a CA. I'll get to the IPA issue after a bit of background in case everyone is not familiar. The external certs we're using are from InCommon and were cross signed by AddTrust and when we originally got the certs, the trust A path was below:
AddTrust Ext CA -> UserTrust CA (intermediate) -> InCommon CA (Intermediate) -> server_cert The B path which should have worked was: UserTrust CA (Root) -> InCommon CA (Intermediate) -> server_cert How OpenSSL is supposed to work is after path A expires, its supposed to use path B. Unfortunately for OpenSSL and OpenLDAP in CENTOS/RHEL 7 and older there is a bug and that does not happen and will not attempt path B. See bugzilla for more information: https://bugzilla.redhat.com/show_bug.cgi?id=1840767 The only way I could get them to walk to path B was to remove the AddTrust CA from all openssl certificate stores. Also, blacklisting doesn't work either as it just made the certs as self-signed. Fortunately there is a path C that we can deploy and force that trust path: Comodo AAA Certificate (Root) -> UserTrust CA (Intermediate) -> InCommon CA (Intermediate) -> server_cert This is also the cert bundle now provided by InCommon. The main issue here is when openssl "builds" the extracted certificates, it adds in the CA's from both /etc/ipa/ca.crt and from katello-ca.crt. We've been able to update the katello and push out that as an RPM, we're having issues with the ca distributed by IDM. ====== actual issue with IPA =============== Post May 30, we could no longer log into IPA. We'd attempted to follow the process for "updating" the certificate. That didn't work. We did an install as we did end up adding a new signed server certificate. That didn't update the Root or the Intermediate CAs. So I went in with a hammer and manually removed the offending AddTrust cert chain A from the following NSSDB files: /etc/httpd/alias /etc/pki/pki-tomcat/alias /etc/dirsrv/slapd-LIDS-VIRGINIA-EDU /etc/ipa/nssdb I also manually cleaned up the /etc/ipa/ca.crt and /etc/pki/ca-trust/source/ipa.p11-kit cert stores. With the above, I was able to get IPA to restart and we could then log into the console and do all we needed to do. The issue now is that the command "ipa-certupdate" still pulls the old AddTrust cert path and I'm pretty sure its because its stored in 389ds. ldapsearch -x -b dc=dom,dc=example,dc=com "(objectClass=ipaCertificate)" | grep Subject ipaCertSubject: CN=Certificate Authority,O=DOM.EXAMPLE.COM ipaCertSubject: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor, ipaCertSubject: CN=USERTrust RSA Certification Authority,O=The USERTRUST Netwo ipaCertSubject: CN=AddTrust External CA Root,OU=AddTrust External TTP Network, How do I update LDAP without things blowing up (oh we're 3 node clustered as well)? Or better yet, is was there a better way to replace certs? Our main com.example.com CA is just fine. All the articles/info I could find was replacing that and not the external CA's. CENTOS/RHEL8 does not have this problem btw. It's fixed in openssl 1.1.1. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
