Hi Mark, I've been away for the weekend. So forgive me my late reply.
Answers below > Am 17.09.2026 um 16:26 schrieb Mark Thomas <[email protected]>: > > 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. JVM Version: 11.0.32+9 JVM Vendor: Eclipse Adoptium >> 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 have started Tomcat with -Dcom.sun.net.ssl.checkRevocation=true -Djava.security.properties=/opt/apache-tomcat.base/conf/java.security.ocsp.add with ocsp.enable=true in the properties file. Adding -Djava.security.debug=certpath,ocsp gave the following logs: certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=logo Intermediate CA 2025, OU=logo, O=logo, ST=Hessen, C=DE certpath: Executing PKIX certification path validation algorithm. certpath: Checking cert1 - Subject: CN=Test Client Cert, OU=logo, ... certpath: -Using checker7 ... [RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 1d4eb2a9 aaae4d7e xxxxxx 2c76fd2b Subject: CN=Test Client Cert, ... Issuer: CN=logo Intermediate CA 2025, ... certpath: connecting to OCSP service at: http://ocsp.fritz.box:8889 certpath: OCSP response status: SUCCESSFUL certpath: Status of certificate (with serial number 389xxxx486...) is: GOOD certpath: OCSP response is signed by an Authorized Responder certpath: -checker7 validation succeeded certpath: Cert path validation succeeded. (PKIX validation algorithm) There was only this one OCSP request to the leaf. Note: the java truststore contains the full chain, otherwise Tomcat can't serve the complete server-cert chain, so removing the intermediate isn't an option here. Which brings me to the conclusion that at least java 11 behaves like Apache or nginx with "SSLOCSPEnable leaf" or "ssl_ocsp leaf". I have checked their configs and that's probably the reason why they work with my chain. Would it be possible to add this as an option "ocspLeafOnly" to native too? The default would stay full-chain (chain), so no behaviour change and CVE-neutral - it would just bring the OpenSSL/native connector in line with what JSSE, Apache and nginx already allow. I have a tested one-line change (gating the OCSP call on errdepth == 0 in SSL_callback_SSL_verify) and would be happy to turn it into a PR if you're open to the scope/naming. Thank you for your support. Peter > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
