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(a)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.
I should point out that the delete command deletes ALL certs for a
nickname so it wouldn't help in this particular case.
rob