Hi,

We further debugged the issue and narrowed down the issue to dynamic update of 
Truststore. We add certificate into TrustStore dynamically. We have to restart 
the server to use the newly added certificate.
This was working fine with Tomcat 7.

Are we missing any configuration detail or any other details required by Tomcat 
9 for this use case?

Regards
Manish

-----Original Message-----
From: Palod, Manish 
Sent: Wednesday, May 5, 2021 9:21 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: RE: Tomcat 9: Client Certificate verification setting with optional is 
not working

Hi Mark,

Thank you for your suggestion. We will try with private browsing mode.
No, we tried in normal browsing mode only. Our issue with optional applies to 
very first-time access only. 
When we tried with certificateVerification="required" first, we were prompted 
with Client certificate, after that we changed the settings back to "optional" 
and still application is working with client certificate, and that is due to 
client certificate is available in cache.

Regards
Manish
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Wednesday, May 5, 2021 1:47 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9: Client Certificate verification setting with optional is 
not working

CAUTION: External email. Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

On 04/05/2021 18:17, Palod, Manish wrote:
> Hi,
> 
> We are in process of migrating from Tomcat 7 to Tomcat 9.
> We use cert-based client authentication in our application,  support 
> password-based and cert-based authentication.
> 
> For this purpose, we are setting certificateVerification="optional" 
> attribute in SSLHostConfig Element of Server.xml [in Tomcat 7, we were 
> setting clientAuth="want" ]
> 
> 
> <Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>                     maxThreads="150" SSLEnabled="true" scheme="https" 
> secure="true" compression="on" 
> compressibleMimeType="text/html,text/xml,text/plain,text/javascript,text/css,application/x-javascript,application/javascript"
>                     address="0.0.0.0"
>                     maxPostSize="10485760"
>                     URIEncoding="UTF-8" server=" ">
>              <SSLHostConfig
>                      truststoreFile="${tomcat.bind.truststore}" 
> truststorePassword="${tomcat.bind.truststorepass}" truststoreType="jks"
>                      ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
>                      certificateVerification="optional" sslProtocol="TLS"
>                      protocols="TLSv1.2">
>                  <Certificate 
> certificateKeystoreFile="${tomcat.bind.keystore}" certificateKeystorePassword 
> ="${tomcat.bind.keystorepass}"
>                               type="RSA" />
>              </SSLHostConfig>
> </Connector>
> 
> When I am trying to access application from browser, where client certificate 
> is available, this use case is not working with 
> setting(certificateVerification="optional"), Tomcat is not requesting for 
> client cert.
> If I change this setting to certificateVerification="required", then this 
> functionality is working as it was working with Tomcat 7.
> 
> 
> Can someone help in understanding why Tomcat 9, setting with "optional" value 
> not working.

I've just tested this locally and certificateVerification="optional" is working 
as expected.

Are you testing with a private browsing window? Browsers can sometimes be 
"helpful" and cache things between sessions. After opting not to provide a 
certificate once, I wasn't prompted gain until I used a private window or 
cleared out the cache.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to