On Fri, Mar 06, 2020 at 12:48:50PM +0200, Alexander Bokovoy via FreeIPA-users wrote: > On pe, 06 maalis 2020, Sigbjorn Lie via FreeIPA-users wrote: > > > On 4 Mar 2020, at 14:27, Alexander Bokovoy via FreeIPA-users > > > <freeipa-users@lists.fedorahosted.org> wrote: > > > > > > On ke, 04 maalis 2020, Sigbjorn Lie via FreeIPA-users wrote: > > > > Hi Alex, > > > > > > > > Thanks for your prompt response. > > > > > > > > There are no Debian/Ubuntu systems in our environment. > > > > > > > > From your response, is the dual CA cert to be expected / by design? > > > > > > Yes, actually, it is to be expected for any setup with external CA root. > > > > This is not an external CA root. I presume both internal and external > > CA root is treated the same then. > > Yes, there is no difference in this sense. In both cases Dogtag owns the > key -- the difference would only be where a self-signed root is located > in a CA path. > > > > > I have not verified what certificate every application in our > > > > environment ends up utilizing yet, as serving both the old and the new > > > > CA certificates seem to me to be a bug, and I would rather fix the bug > > > > than make workarounds. > > > > > > No it is not a bug. It is normal and common to have multiple CA roots > > > available in a certificate store. The checks are done against a valid > > > CA root for the specific certificate and if you have one issued with the > > > use of older CA root certificate, you need to verify against that. > > > > This does not seem to be correct for IPA. As far as I recall there was > > a feature for making sure at that the renewed IPA CA certificate (when > > using self-signed CA cert) continue to work for the existing issued > > certificates. Verifying a certificate that was issues by the old CA > > against the new CA returns OK, and there are no issues connecting to > > the website. > > > > sudo openssl verify -verbose -CAfile /etc/ipa/ca-new.crt > > /etc/pki/httpd/website1.crt > > /etc/pki/httpd/website1.crt: OK > > openssl verification is done down to a self-signed trust anchor. If your > new CA root is using the same key (no re-keying happened on CA root > renewal), the same key is in place, and IPA CA is self-signed, that's > why it works. My understanding is that if you re-keyed CA root > certificate on renewal, this wouldn't be true and you would need the old > CA certificate to validate these server certificates. > > I might be wrong here, though. See man page for openssl-verify, section > 'VERIFY OPERATION' for some logic description. > > > > What I'd like to get clear is why are you pointing the applications to > > > /etc/ipa/ca.crt? Supposedly, the content of this file is already a part > > > of the system-wide certificate store. On RHEL/CentOS/Fedora systems the > > > way how system-wide store works, there are multiple representations that > > > are supported by all crypto libraries and frameworks. So you don't need > > > to put a direct reference to /etc/ipa/ca.crt. > > > > We have been using IPA in production since 2012. In testing even a > > couple of years earlier. Back then the only place the ca cert was > > written to the client was /etc/ipa/ca.crt, and so this is what has been > > used in our Puppet setup ever since the beginning. The fact that the > > ipa-client installs the CA certificate in the system-wide certificate > > store is a more recent development. > > (https://pagure.io/freeipa/issue/3504) > > Understood. The ticket mentioned was closed in 2014, so we are talking > about all RHEL 7+/Fedora 19+ systems. > > > > > > Back to my original question, what is the reason for keep serving the > > > > old certificate? Would it not be sufficient to serve only the new > > > > certificate to new clients being enrolled and clients using the > > > > ipa-certupdate command? > > > > > > It is to allow clients to verify certificates issued with the previous > > > CA root certificate. Until you have renewed all certificates issued with > > > the old CA root, you need to keep that in place or clients/servers using > > > that wouldn't be able to trust the certificate. > > > > This is perhaps true for most PKI setups, however as mentioned, I seem > > to recall that a a feature for making sure at that the renewed IPA CA > > certificate (when using self-signed CA cert) continue to work for the > > existing issued certificates. Again, openssl returns OK when verifying > > existing certificates with the new CA, and there are no issues > > connecting to the website where this is hosted. > > > > sudo openssl verify -verbose -CAfile /etc/ipa/ca-new.crt > > /etc/pki/httpd/website1.crt > > /etc/pki/httpd/website1.crt: OK > > > > > > As this duplicated CA cert is a feature, what will happen when we move > > pass the expiry date of the old CA? Will it be automatically removed > > from IPA or is there any manual cleanup required? > > There is no automatic cleanup right now. I thought we had a ticket for > the clean up tool but I cannot find it right now. Please open one? > Rob recently implemented `ipa-cacert-manage delete` subcommand, on master and ipa-4-8 branch (there hasn't been a release containing it yet, though). It can be used to remove a specified certificate from the IPA trust store. But it is not automatic.
If expired CA certs are present in trust stores, clients will (or should) ignore them. Cheers, Fraser _______________________________________________ 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
