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.
Hi,
starting from IPA 4.8.5 [1], the command ipa-cacert-manage provides the
"delete" subcommand in order to remove a CA cert from LDAP store.
If you are using an older release, the steps are manual and require
removing the certificate from LDAP. The procedure has already been
discussed in this mailing list, see for instance this archive [2].
HTH,
flo
[1]
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...