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.
> 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
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)
> 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?
Regards,
Siggi