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?

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.

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?


Regards,
Siggi




On 4 Mar 2020, at 13:51, Alexander Bokovoy <abokovoy@redhat.com> wrote:

On ke, 04 maalis 2020, Sigbjorn Lie via FreeIPA-users wrote:
Hi,

We recently renewed our IPA CA cert using the "ipa-cacert-manage renew”
command. The renewal was successful, and our CA cert no longer expires
in 2020, but in 2040.

Running “ipa-certupdate” on existing IPA clients and ipa-client-install
on new IPA clients also works, however both the new and the old CA cert
is pulled down to the IPA client and stored in /etc/ipa/ca.crt.

This creates some issues as most applications reading /etc/ipa/ca.crt
only reads the first entry, which happens to be the old CA cert.

For the moment everything works OK as the old CA cert is still valid,
however this will become a major issue in a few months time.

Is this expected? To continue to service both the old and the new CA
certificate to old and new IPA clients?  Will the old certificate be
automatically removed at some point?  If not, what is the safe steps to
remove the old CA certificate from the IPA servers?

Could you please detail what systems are not able to process multi-cert
ca.crt? Is that any of Debian/Ubuntu systems?

What applications you are encountering the problem with?

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland