Hi, after a long break I did find some time to get back to this problem and I do have some new findings.
After digging through the logs again, I did research on some error messages and found some hints that this could also be related to some OCSP check failing. In /etc/httpd/conf.d/ssl.conf I could find the "SSLOCSPEnable on" directive. After setting this to off, everything started working again and I was able to get a new replica up and running. I did expect the new replica to misbehave in the same way but it didn't. There also is no "SSLOCSPEnable" directive in the ssl.conf of the replica. This brings me to the question, if there has been a change in FreeIPA at some point and maybe a config migration or something failed. Do you know if the current correct state of httpd config is an enabled or disabled OCSP verification? Thank you and best regards Hannes On Tue, 2025-01-28 at 13:59 -0500, Rob Crittenden via FreeIPA-users wrote: > Hannes Eberhardt wrote: > > > > Hi Rob, > > > > > Have you recently replaced the CA chain and/or the IPA server > > > cert(s)? > > > Apache and/or DS? > > > > > No, I have neither replaced any of the internal certs nor the > > certficate chain. > > You could try creating /etc/ipa/server.conf with contents: > > [global] > debug = True > > Then restart the httpd service. > > You might get more or better error messages about the failure. > > Note that the debugging is rather long winded so you may not to leave > it > running long. > > You could also try re-exporting the cert chain. > > # ipa-certupdate > > > > > > > > > > This means that one of the CA subsystem certificates was not > > > found by > > > the CA which is unexpected, hence the backtrace. You can try > > > running > > > healthcheck again and then watching the DS access log to find the > > > query > > > that returned nothing (err=32). That will tell you which subject > > > it > > > couldn't find. > > I've searched the slapd access log while running ipa-healtcheck for > > err=32. The log is very long but there are "only" four occurences > > of > > err=32. I think this should be the relevant lines that share the > > same > > op/operation(?) value. > > [...] > > [26/Jan/2025:12:56:33.608141106 +0100] conn=1847 op=10 SRCH > > base="cn=DNSSEC,cn=idm- > > [...],cn=masters,cn=ipa,cn=etc,dc=idm,dc=[...],dc=[...],dc=[...]" > > scope=0 filter="(objectClass=*)" attrs="cn" > > [26/Jan/2025:12:56:33.608208600 +0100] conn=1847 op=10 RESULT > > err=32 > > tag=101 nentries=0 wtime=0.000048841 optime=0.000068771 > > etime=0.000116566 > > [...] > > [26/Jan/2025:12:56:36.433609457 +0100] conn=1857 op=3 SRCH > > base="cn=changelog5,cn=config" scope=0 filter="(objectClass=*)" > > attrs="nsslapd-changelogmaxentries" > > [26/Jan/2025:12:56:36.433639656 +0100] conn=1857 op=3 RESULT err=32 > > tag=101 nentries=0 wtime=0.000173461 optime=0.000030915 > > etime=0.000203514 > > [...] > > [26/Jan/2025:12:56:36.434644495 +0100] conn=1847 op=18 SRCH > > base="cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config" scope=0 > > filter="(objectClass=*)" attrs="* aci" > > [26/Jan/2025:12:56:36.434671918 +0100] conn=1847 op=18 RESULT > > err=32 > > tag=101 nentries=0 wtime=0.000090959 optime=0.000028427 > > etime=0.000118526 > > [...] > > [26/Jan/2025:12:57:14.989604635 +0100] conn=5 op=8240 SRCH > > base="cn=docarch.[...],cn=masters,cn=ipa,cn=etc,dc=idm,dc=[...],dc= > > [... > > ],dc=[...]" scope=0 filter="(objectClass=*)" attrs=ALL > > [26/Jan/2025:12:57:14.989643954 +0100] conn=5 op=8240 RESULT err=32 > > tag=101 nentries=0 wtime=0.000037066 optime=0.000039544 > > etime=0.000076147 > > [...] > > > > If I did understand the logs right,there are a few objects missing: > > A > > DNSSEC cert, a changelog, something replica related and a service > > certificate I've signed by the CA. > > Returning no entries not necessarily an error. In this case the > backtrace showed a failure searching with filter like > 'subjectname=<something>'. That isn't in any of your findings. > > > > I can't explain why a certificate would go missing. Did you have > > > any > > > recent db corruption? Did anyone attempt to "clean up" some > > > records? > > > > > I can rule out the "someone cleaning up" part, but I can't rule out > > a > > database corruption. Is there maybe a way to check for this? > > Stop your DS instance. > > # dsctl -v EXAMPLE-TEST dbverify userroot > > 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
