Perfect, Thank you Mark! Thanks for taking this to dev@. Happy to test a patch against my chain whenever there's something to try.
Kind regards Peter > Am 22.09.2026 um 13:35 schrieb Mark Thomas <[email protected]>: > >> On 21/09/2026 12:55, [email protected] wrote: >> 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. > > That is the difference. Including the intermediate cert in the trust store > means that cert is treated as a trust anchor by JSSE so no OCSP validation is > performed. > > The Tomcat Native OCSP checks only terminate for a root CA. That could be > changed to terminate for any certificate in the trust store. I'll start a > discussion about that on the dev@ list. > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
