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 mailto: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