On 17/09/2026 12:44, [email protected] wrote:
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?
Interesting. Which version of Java and which vendor? I looked at the
latest OpenJDK code but I didn't run any tests so I might have missed
something.
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?
If I am reading the Java code correctly and the information I read
online is accurate (never certain) then yes, I would say this isn;t a
Tomcat issue.
I'm prepared to be proved wrong though.
Mark
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
