Fraser Tweedale wrote: > On Tue, Mar 10, 2020 at 10:25:01AM -0400, Rob Crittenden wrote: >> Fraser Tweedale via FreeIPA-users wrote: >>> 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 >>>>>> <[email protected]> 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. >> >> I should point out that the delete command deletes ALL certs for a >> nickname so it wouldn't help in this particular case. >> > > Thanks for the clarification, Rob. > > If you need to remove just a single cert for the same subject (e.g. > an older expired one), you can delete that particular > userCertificate attribute value from its LDAP entry under > cn=certificates,cn=ipa,cn=etc,{basedn}. > > I also want to clarify that it is expected behaviour for IPA will > put all trusted CA certs, including possibly expired variants, in > the /etc/ipa/ca.crt and other system trust stores. If it is causing > an issue for some other program, the problem is with that program, > not with FreeIPA.
I completely agree but practically speaking an expired CA isn't all that useful is it? Makes me look at this a different way. Perhaps change the certstore to only return valid CA certs. That way they are stored if anyone ever wants them but they won't get pulled down for ipa-certupdate or ipaclilent-install. Or to try the ipa-cacert-manage route, it was mostly the UI part for why I didn't do it. I wasn't sure if the best way would be to interactively show each cert and do a delete Y/N or what. Perhaps a delete with --expired-only to do the cleanup. I'm open to suggestions. rob _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
