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]
