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?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland