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]
For additional commands, e-mail: [email protected]
