Hi Mark,
before I look into the details I want to note that the existing certificate chain validates with OCSP in JSSE just fine (my other tomcat connector uses JSSE). Is this what you meant with my description? If this is how JSSE works, is there a security issue too? I agree that it would be best to add revocation info to the intermediate, but this is nothing that can be done in a minute. I doubt that a central OCSP responder will change anything in this case - there is no revocation handling for the intermediate... Would a change in this be against an existing CVE? The case of missing AIA within the chain is not an issue of tomcat but of the certificate provider (me), right? Peter > Am 17.09.2026 um 11:48 schrieb Mark Thomas <[email protected]>: > > On 16/09/2026 22:36, [email protected] wrote: >> 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. >> What do you think? > > If you look back at the CVEs for Tomcat Native they are all related to OCSP. > > In the current release round there was a deliberate effort to review the OCSP > code across all the Connectors (JSSE, OpenSSL-Native and OpenSSL-FFM). The > aim was to close any remaining gaps and to make the behaviour consistent > whichever TLS implementation was used. > > The behaviour you describe is how Java implements OCSP. > > Revoking the intermediate cert does not automatically revoke the certs it > issued. But it does mean that those certificates should no longer be used. So > if you care enough about OCSP not to use soft-fail then you should also be > checking the validity of the intermediate certs. Which means they need > responder URLs. > > If you are using JSSE, you can set a global OCSP responder that is used > *instead* of any URI defined in the certificate via the ocsp.responderURL > system property. > > There isn't an OpenSSL equivalent. > > A global responder URI seems rather inflexible but per SSLHostContext looks > reasonable. It looks relatively simple to add support for an ocspResponderURL > to SSLHostConfig which would override any responder URL provided by the > certs. This isn't something I'd have to the time to write any time soon but I > should be able to find time to review a PR. > > Mark > > --------------------------------------------------------------------- > 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]
