Hi Mark, I have managed to get main compiled. (not that easy. recreating the magic release stuff to get to the same level of the src package).
Your change works perfectly. Thank You. tomcat | [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] tomcat | [OCSP-DBG] depth=1 result=2 err=0(ok) soft_fail=0 subj=/C=DE/ST=Hessen/O=logo/OU=logo/CN=logo Intermediate CA 2025/[email protected] tomcat | [OCSP-DBG] depth=0 result=0 err=0(ok) soft_fail=0 subj=/C=DE/ST=Hessen/L=Dreieich/O=logo/OU=logo/CN=Test Client Cert ssl_verify_OCSP reaches depth 0 without an error on depth 1 :-). Hoping to see a release soon. Good night! Peter > Am 23.09.2026 um 15:00 schrieb Mark Thomas <[email protected]>: > > On 22/09/2026 15:49, Peter Kreuser wrote: >> Perfect, Thank you Mark! >> Thanks for taking this to dev@. Happy to test a patch against my chain >> whenever there's something to try. > > The latest 2.0.x and 1.3.x Native sources at > https://github.com/apache/tomcat-native should have a fix for this. > > Mark > > >> 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]>
