Alex,
On 5/9/25 2:11 PM, My Subs wrote:
I have tested on Tomcat 10.1.40 with Native
Library 1.3.1 running on JDK 21.0.7+6. The result is exactly the
same as described before. The connector below works well with client
authentication, until I add the caCertificatePath attribute. There
are no error messages in the logs.
Thanks for confirming that.
It probably does not matter, but what OS are you using, and what version
of OpenSSL are you using?
<Connector
protocol="HTTP/1.1"
port="8443"
SSLEnabled="true"
maxParameterCount="1000"
>
In your earlier message, you had a different configuration. This time
you haven't specified the class name in the "protocol" attribute. Which
one are you actually using?
<SSLHostConfig
protocols="TLSv1.3"
certificateVerification="required"
caCertificatePath="tls/client/certs-ca"
>
<Certificate
certificateKeyFile="tls/server/localhost-key.pem"
certificateFile="tls/server/localhost-cert.pem"
/>
</SSLHostConfig>
<UpgradeProtocol
className="org.apache.coyote.http2.Http2Protocol"
/>
</Connector>
This time around, Firefox only shows "0 B" on the
"Transferred" column of the "Network" tab in
developer tools.
Any ideas on what could be wrong?
So the above configuration works for all requests that do not try to
send a client certificate during the handshake?
It's only when you try to send a client certificate that things stop
working?
When they stop working, does that mean that no more requests are
accepted and processed, or is it that handshakes fail with client certs
but handshakes without client certs work okay?
If you connect to your server like this, what does the output look like:
$ openssl s_client -showcerts -connect https://host/whatever
This would usually give you a list of allowable client certificates like
this:
"
Acceptable client certificate CA names
(cert 1)
(cert 2)
...
(cert N)
"
I'm interested in what that returns, if anything.
-chris
---- On Wed, 07 May 2025 12:37:16 -0500 Chuck Caldarale <n82...@gmail.com>
wrote ---
On 2025 May 7, at 11:43, My Subs <mailto:my.s...@zoho.com.invalid> wrote:
I'm setting up certificate client authentication on Tomcat 10.0.0
running on Java 16+36.
Before doing anything else, you need to upgrade. That version of Tomcat is over 4 years old, and no 10.0.x version is currently supported. Move up to the 10.1.x level (current version is 10.1.40) and see if your issue has already been addressed.
- Chuck
I'm having trouble getting it to work with a
CRL. My SSL connector is:
<Connector
protocol="org.apache.coyote.http11.Http11AprProtocol"
port="8443"
SSLEnabled="true"
maxParameterCount="1000"
>
<SSLHostConfig
protocols="TLSv1.3"
certificateVerification="optional"
caCertificatePath="conf/ca-certs"
certificateRevocationListPath="conf/ca-crls"
>
<Certificate
certificateKeyFile="conf/localhost-ec-key.pem"
certificateFile="conf/localhost-ec-cert.pem"
/>
</SSLHostConfig>
<UpgradeProtocol
className="org.apache.coyote.http2.Http2Protocol"
/>
</Connector>
In my PKI setup (using OpenSSL), I have a root CA
(cert: root-ca.pem), and a subordinate CA (cert: sub-ca-01.pem),
which signs leaf certificates, and issues a CRL (crl:
sub-ca-01-crl.pem).
File root-ca.pem is in conf/ca-certs. File
sub-ca-01-crl.pem is in conf/ca-crls, as follows:
0551d8aa.r0 -> sub-ca-01-crl.pem
c79c8ddb.r0 -> sub-ca-01-crl.pem
sub-ca-01-crl.pem -> /home/me/somedir/sub-ca-01-crl.pem
Before adding to <SSLHostConfig>, attribute
«certificateRevocationListPath="conf/ca-crls"», client
authentication works fine. The servlet can see a valid client
certificate and extract its attributes from the X509Certificate
object returned by
request.getAttribute("jakarta.servlet.request.X509Certificate").
However, once I add attribute
certificateRevocationListPath, the connector stops responding to
requests that present a client certificate regardless of whether the
certificate is valid or revoked —it still responds though if the
request does not present a client certificate.
Firefox only shows error NS_ERROR_FAILURE on the
"Transferred" column of the "Network" tab in
developer tools.
The CRL is not expired (and it won't be for long),
as its printout shows:
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = Sub CA 01
Last Update: May 6 21:53:22 2025 GMT
Next Update: Apr 12 21:53:22 2125 GMT
CRL extensions:
X509v3 CRL Number:
4097
Revoked Certificates:
Serial Number: 82AB03509A91A8DCCBA0CE62A67417B6
Revocation Date: May 6 21:51:40 2025 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Unspecified
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:f7:98:07:1f:2f:cf:d5:ad:b7:5e:20:61:de:
1b:7b:1f:c7:74:f9:80:33:d8:a2:cc:3a:75:28:4c:64:65:93:
c1:02:20:5b:3e:e9:dd:52:9e:11:9b:45:5a:53:fc:2f:bb:b3:
f4:db:52:64:f6:ea:13:54:43:d6:54:2b:f3:28:03:ae:6f
The problem persists if I drop attribute
certificateRevocationListPath, and replace it with
«certificateRevocationListFile="conf/ca-crls/sub-ca-01-crl.pem"».
It persists as well if I add to conf/ca-crls a CRL for the root CA.
I found nothing helpful in the logs. The source
of the problem escapes me. How can I get certificate client
authentication to work with CRLs in Tomcat?
Help is appreciated. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: mailto:users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
