9:54 a.m.
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.