https://bz.apache.org/bugzilla/show_bug.cgi?id=69988

            Bug ID: 69988
           Summary: certificateVerification="none" with CLIENT-CERT does
                    not work
           Product: Tomcat Native
           Version: 2.0.14
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Library
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

I want to use TLSv1.3 post-handshake authentication (PHA) in order to require
client certificates only on certain protected URLs. The Tomcat documentation
(here, for example:
https://tomcat.apache.org/tomcat-11.0-doc/config/http.html#SSL_Support_-_SSLHostConfig)
states that this can be accomplished with a combination of the following:

- SSLHostConfig with certificateVerification="none"
- Protected resources in web.xml with <auth-method>CLIENT-CERT</auth-method>
- Tomcat Native with OpenSSL (since JSSE does not support PHA)

With this setup, the server hangs for 60 seconds when attempting to access
client-cert-protected resources then times out and sends an empty response.

Using curl at the command line (with -v, --cert, and --key) shows that Tomcat
(Native?) correctly sends the CertificateRequest message, curl correctly sends
the client certificate, and Tomcat (Native?) sends a new TLS session. But then
Tomcat appears to hang (waiting for a handshake, maybe?).

If I downgrade to TLSv1.2, everything works as desired.

If I use certificateVerification="required", protected resources work as
desired (no hang, client cert requested). But unprotected resources also
request a cert, which is not what I want. "optional" also works similarly.

My test environment:
Tomcat 11.0.20
Tomcat Native 2.0.14
APR 1.7.6
OpenSSL 3.0.13
Ubuntu 24.04.4 LTS

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to