I wonder I if have gotten myself in a bind.
I have a small realm of a dozen Rhel7 and Rhel8 servers, a few dozen users and
three IDM servers. We moved from yellow pages to IDM for 2FA a couple of years
ago. The original IDM servers were all Rhel7. In November of 2021, we moved
to IDM 4.9 on Rhel8.4 by standing up new IDM servers and replicating.
When we finished the migration there were no significant healtcheck (hc)
errors. Over the next year we upgraded to 8.5, 8.6 and then 8.7.
At some point and I believe it was when we got to Rhel8.6 we started getting hc
errors with this type of message:
"msg": "Certificate 'subsystemCert cert-pki-ca' does not match the value of
kra.subsystem.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
On two of the IDM servers the messages were for:
kra_subsystem
kra_transport
kra_storage
kra_audit_signing
all showing a missmatch in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg
There was one other similar message:
"transportCert cert-pki-kra had a mismatch in
/var/lib/pki/pki-tomcat/conf/ca/CS.cfg
At the time we googled the issue and came up with:
https://github.com/freeipa/freeipa-healthcheck/issues/154
where Rob Crittenden says:
"We seem to have lost traction on this. It is my understanding that the
certificates not matching the values in CS.cfg is not a critical problem. It is
checked to ensure consistency."
So we ignored the errors
After upgrading to 8.7 in November 2022, we started getting more hc errors
regarding iDNS. Google led us to a script to fix the problem which we ran and
the problem went away.
I was still concerned with the CS.cfg mismatches, so I decided to fix the
messages. An inventory of the messages showed two IDM servers with the
messages listed above and one IDM server with an sslserverCert in ...kra/CS.cfg
and transportCert in ...ca/CS.cfg mismatch errors.
Since this was only a sanity check, I modified the cert hashes in each CS.cfg
to match the cert generated by:
certutil -d /etc/pki/pki-tomcat/alias -L -n '<cert nickname>' -a by pasting the
trimmed hash into the appropriate directive in the corresponding CS.cfg.
Now when I run ipa-healthcheck, there are no errors. My concern is that
perhaps I have broken Dogtag and when some of these certs go to be renewed in
February, there will be problems.
I also note that for all 14 of these cert directives I modified in CS.cfg there
was also a "<directive.certreq=>" pointing to a hash in CS.cfg that I didn't
modify.
Is my system in trouble? How do I resolve this? Since all the errors are only
in CS.cfg, is there a way to generate a fresh CS.cfg? Most of the articles
I've found regarding fixing corrupt CS.cfg files, are old and incredibly
complex.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
