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]
