Hannes Eberhardt via FreeIPA-users wrote: > 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?
IPA disables OCSP during installation. This is why on your replica it is disabled. The only place that IPA enables OCSP is in ipa-advise when configuring smart cards. rob > 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
