I have notice a regression when testing a SSL mutual authentication configured in the web.xml whith auth-method set to CLIENT-CERT. My configuration in web.xml : <security-constraint> <web-resource-collection> <web-resource-name>My app unprotected</web-resource-name> <url-pattern>/my/other/page.jsp</url-pattern> </web-resource-collection> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>My app protected</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>MyAppRole</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <role-name>MyAppRole</role-name> </security-role> In my server.xml, the connector is configured with the following section : <Connector port="8443" protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true" scheme="https" secure="true" maxThreads="150" minSpareThreads="25" enableLookups="false" disableUploadTimeout="true" acceptCount="100" URIEncoding="UTF-8"> <SSLHostConfig protocols="+TLSv1.3,+TLSv1.2" ciphers="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" truststoreFile="/my/truststore.jks" truststorePassword="yyyy" truststoreType="JKS"> <Certificate certificateKeystoreFile="/my/keystore.jks" certificateKeystorePassword="xxxx" certificateKeystoreType="JKS"/> </SSLHostConfig> </Connector> When accessing the protected resources, there is no prompt in the navigator to select the SSL client certificate. Instead of what a status code 401 is returned. Everything works fine if certificationVerification is set to required. It works too if certificationVerification is omitted (default value set) and TLSv1.3 is desabled in the the protocols parameter value of SSLHostConfig element. I activated the logs to search the differences : org.apache.catalina.realm.level = ALL org.apache.catalina.realm.useParentHandlers = true org.apache.catalina.authenticator.level = ALL org.apache.catalina.authenticator.useParentHandlers = true Logs when it doesn't work: 16-Oct-2019 16:22:12.990 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[My app protected]' against GET /my/protected/page.jsp --> true 16-Oct-2019 16:22:12.990 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[My app unprotected]' against GET /my/protected/page.jsp --> false 16-Oct-2019 16:22:12.990 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[My app protected]' against GET /my/protected/page.jsp --> true 16-Oct-2019 16:22:12.990 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking constraint 'SecurityConstraint[My app unprotected]' against GET /my/protected/page.jsp --> false 16-Oct-2019 16:22:12.993 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations Loading persistent provider registrations from [/etc/tomcat/conf/jaspic-providers.xml] 16-Oct-2019 16:22:13.013 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling hasUserDataPermission() 16-Oct-2019 16:22:13.014 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.realm.RealmBase.hasUserDataPermission User data constraint has no restrictions 16-Oct-2019 16:22:13.014 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling authenticate() 16-Oct-2019 16:22:13.018 FINE [https-jsse-nio2-8443-exec-9] org.apache.catalina.authenticator.AuthenticatorBase.invoke Failed authenticate() test
JSSE does not support post-handshake authentication with TLS 1.3. Work-arounds are available (use OpenSSL or drop-back to TLS 1.2). Further assistance is available on the users mailing list if required.
(In reply to Mark Thomas from comment #1) > (use OpenSSL or drop-back to TLS 1.2). Clarification: does NIO+OpenSSL+TLSv1.3 work, here, or is the APR connector required?