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? Thank you for looking into this. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
