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
<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.
>>
>
> 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
I think it's fine to change ipa-certupdate so it skips expired /
not-yet-valid certs.
IMO we should never automatically prune expired certs from the LDAP
trust store, so that if customer needs to do time travel to fix an
issue, the old CA certs will still be there and an ipa-certupdate
will "restore" them to the various certificate DBs.
And for the same reason, I'd be hesitant to offer a UI to prune
expired certs from the trust store.
Cheers,
Fraser