Bob Strachan via FreeIPA-users wrote:
> 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. 

As I mentioned in healthcheck upstream, the CS does not consider the
certificate blobs to be a critical issue. You fixed them, that's fine.
I'd probably make sure to keep a copy of CS.cfg prior to tweaking it for
general safety. There is no way that I know of to regenerate it from
scratch for a given system.

I'm not sure why you think you've broken dogtag by doing this. Does the
CA start up? Can it issue certificates? Can you create a vault?

You don't have to wait on pins and needles. If you want extra breathing
room for when renewal happens you can set enroll_ttls in
/etc/certmonger/certmonger.conf and restart it (see man page for details).

You can, for example, add a 60-day renewal value, then restart certmonger:

enroll_ttls = 5184000, 2419200, 604800, 259200, 172800, 86400, 43200,
21600, 7200, 3600

That would cover past the end of February so it should start renewing
immediately.

Note that renewal may not complete in one pass and that's usually ok.
Renewal involves restarting the CS for each updated cert and there are
minimum 5 to renew, plus the LDAP and HTTP certs, so there is a lot of
work to do.

rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
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/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to