Hi Stefan, this is valuable information (and I'd have a ton of work to do if this would be enforced) . However this does not seem to be the issue here. Native checks the AIA/OCSP URI only (not X509v3 CRL Distribution Points).
Featureflags may be a hassle. If need be I could also go with ocspSoftFail="true". But I'd like to see all the implications of this setting. I'm curious how this is seen by the developers. Peter Peter Kreuser Liebknechtstr. 83 63303 Dreieich-Sprendlingen phone: +49 6103 9880863 fax: +49 6103 9886215 mobile: +49 172 6649346 email: [email protected] web: www.kreuser.name key: http://www.kreuser.name/PGP_Public_Key.txt smime: http://www.kreuser.name/SMIME.cer > Am 17.09.2026 um 00:47 schrieb Stefan Mayr <[email protected]>: > > Hi > > Am 16.09.2026 um 23:36 schrieb [email protected]: >> Hello, >> I have found some troubles with the new OCSP changes. >> My mTLS access to my host fails since 9.0.122 with tomcat native 2.0.16. >> The same client cert with the ocsp reponder works fine with apache, nginx, >> haproxy... >> I can only make my client cert (signed by my own internal CA) work with >> ocspSoftFail="true". >> I was trying to figure out how I could troubleshoot this. I am compiling >> tomcat native in a Docker image. So I asked claude.ai for help to get some >> meaningful debug messages into the code. >> Claude asked a couple of questions about the setup of my CA and the symptoms >> and the changes between 2.0.15 and 2.0.16. Interestingly we figured out that >> it may have to do with AIA and commit 9c6bb9d (Stricter OCSP handling when >> soft-fail is disabled - AIA extension is not present or no URLs were found). >> My certificate chain contains the intermediate WITHOUT an OCSP URI! >> [OCSP-DBG] depth=2 result=2 err=0(ok) soft_fail=0 >> subj=/C=DE/ST=Hessen/L=Dreieich/O=logo/OU=logo/CN=logo Root >> CA/[email protected] >> [OCSP-DBG] depth=1 result=2 err=3(unable to get certificate CRL) soft_fail=0 >> subj=/C=DE/ST=Hessen/O=logo/OU=logo/CN=logo Intermediate CA >> 2025/[email protected] >> When going through the chain, depth 2 is the root that is apparently not >> checked/reset. Then the intermediate on depth 1 errors and stops the whole >> OCSP handling. >> We're not getting to depth 0. >> In my opinion this error on depth 1 is too strict. The missing OCSP URI on >> the intermediate could be ignored as the only (truly) relevant OCSP URl is >> for depth 0: the real client cert. >> I would think to either validate only "existing" OCSP URIs or validate only >> depth 0. > I stumbled accross something similar with curl on Windows using schannel and > a middle box issuing non-compliant certificates: the CA did not include any > CRL distribution point in the certificate. With this commit I googled my way > to the current CA/Browser forum baseline requirements. There we find in > https://cabforum.org/working-groups/server/baseline-requirements/requirements/#712112-crl-distribution-points: > > The CRL Distribution Points extension MUST be present in: > - Subordinate CA Certificates; and > - Subscriber Certificates that 1) do not qualify as “Short-lived Subscriber > Certificates” and 2) do not include an Authority Information Access extension > with an id-ad-ocsp accessMethod. > > The CRL Distribution Points extension SHOULD NOT be present in: > - Root CA Certificates. > > The CRL Distribution Points extension is OPTIONAL in: > - Short-lived Subscriber Certificates. > > The CRL Distribution Points extension MUST NOT be present in: > - OCSP Responder Certificates. > > As mTLS is a dying species with public CAs I guess you use a private CA (do > we call them private PKI? The P is not for "Public" any more). Is it right to > apply the rules for public certificates here? Should we have feature flags to > disable specific rules für private CAs? > > I know distinguishing between private and public adds a lot of technical > complexitiy. But with the CA/Browser forum becoming stricter I currently see > a lot of things in enterprise environments falling part even if they should > not be affected. And I have to admit, that the stricter rules will be assumed > best practice in the near future and we can expect the less restrictive > CAs/certificates will be flagged in upcoming security audits. > > Just some thoughts, > > - Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
