Hi, On Mon, Jun 30, 2025 at 3:22 PM Hannes Eberhardt via FreeIPA-users < [email protected]> 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. > IIRC this setting is enabled when the server is configured for smart card authentication. flo > > 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 -- [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 >
-- _______________________________________________ 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
