Hello Christopher,
I'm answering below.
>When you have configured a CRL, are *all* requests rejected,
or only
those which include a client certificate during the
handshake? I see you
have configured
certificateVerification="required" so maybe there are no
modes of operation where client certificates are used.
>I'm
trying to understand whether this is a problem with the whole setup
when CRLs are added, or only a problem when a client
certificate is
actively being checked against the CRL.
I believe you are
right in suspecting that it is "only a problem when a client
certificate is
actively being checked against the CRL".
To test this, I set
certificateRevocationListPath to the directory having the CRL file;
changed to certificateVerification="optional"; and
downgraded to HTTP 1.1 (as mentioned, "optional" does not
work with HTTP 2). The result is that requests without a client
certificate get a 200 OK response.
However, *all*
requests having a client certificate (valid or revoked) are rejected.
If the client certificate is revoked, it is correctly identified as
such. Firefox displays message "SSL peer rejected your
certificate as revoked. Error code: SSL_ERROR_REVOKED_CERT_ALERT".
If the client certificate is not revoked, the connection fails with
Firefox displaying an unexpected message: "Peer does not
recognize and trust the CA that issued your certificate. Error code:
SSL_ERROR_UNKNOWN_CA_ALERT".
But that same
issuing CA is perfectly recognized when the
certificateRevocationListPath attribute is removed from the
connector. Requests with a non-revoked client certificate get a 200
OK response, and that certificate is made visible to servlets as a
java.security.cert.X509Certificate object. This holds both for "optional" and
"required" verification.
It's CRL checking
what triggers the error.
> Does the
connection actually hang, or do you simply get a failed (but
complete) handshake?
From
the above, I'd say that the handshake is failed, but complete, since
FF displays those error messages.
> This
looks like a problem. Do you have the trusted certificates
configured correctly? I would have expected Tomcat to send a
list of
acceptable certificates back to the client. That's not
strictly required
by the TLS spec, but it's handy for debugging
like this.
I'm
not sure whether the message "No client certificate
CA names sent" means a problem with the trust store. As you can
see from my connector, caCertificatePath is set to the trust store directory. It
contains the certificate of the root CA, which signed the certificate
of the subordinate CA. The client certificates used in the above
test are signed by that subordinate CA. And as
shown, those are correctly verified when no CRL is configured.
> If you do not configure the CRL, are any CA certs listed in
this output?
> I haven't used TLS with
Tomcat much, so I'm not entirely sure what to
expect.
No. Message "No
client certificate CA names sent" is still there. The full
output is:
CONNECTED(00000003)
Can't use
SSL_get_servername
depth=0 CN =
localhost
verify
error:num=18:self signed certificate
verify return:1
depth=0 CN =
localhost
verify return:1
---
Certificate chain
0 s:CN = localhost
i:CN = localhost
-----BEGIN
CERTIFICATE-----
MIIBfzCCASWgAwIBAgIUBtGtuw6cAZvC560e0RVjnI/+tnwwCgYIKoZIzj0EAwIw
FDESMBAGA1UEAwwJbG9jYWxob3N0MCAXDTI1MDQxNjIyNTg0OFoYDzIxMjUwMzIz
MjI1ODQ4WjAUMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjO
PQMBBwNCAASWvdHleExdyTqn+wXgNY3XueCLjkkpbrtVhw8lB4DsmkTJDUCdszZX
9ElKT01bP10cX+mrinNNEtgKFPBwcTCXo1MwUTAdBgNVHQ4EFgQUJIQfq2nU9T2J
uexYvw1bqosji6cwHwYDVR0jBBgwFoAUJIQfq2nU9T2JuexYvw1bqosji6cwDwYD
VR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiAUmPONFAU4ThvidgLnlXiu
7XElAkAGfmlXKkN0DgJWwAIhAPkF8ngCXY4G7Y2obrGUS2u80p06O2ZYFtXyrM3+
UuRN
-----END
CERTIFICATE-----
---
Server certificate
subject=CN =
localhost
issuer=CN =
localhost
---
No client
certificate CA names sent
Requested Signature
Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:E
d448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:
RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed
25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+
SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest:
SHA256
Peer signature type:
ECDSA
Server Temp Key:
X25519, 253 bits
---
SSL handshake has
read 824 bytes and written 393 bytes
Verification error:
self signed certificate
---
New, TLSv1.3, Cipher
is TLS_AES_256_GCM_SHA384
Server public key is
256 bit
Secure Renegotiation
IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not
sent
Verify return code:
18 (self signed certificate)
---
---
Post-Handshake New
Session Ticket arrived:
SSL-Session:
Protocol :
TLSv1.3
Cipher :
TLS_AES_256_GCM_SHA384
Session-ID:
E820564C0A376A2F9D412227668B9682EE9ABA97DFFE752A2C1289817934735C
Session-ID-ctx:
Resumption PSK:
D7BD928F4D23B9AB8D030E5347C6BA32049D9D2235F4A6FF832A28651B48649EE4EB191BDF40D9FA89C120C3429843A9
PSK identity:
None
PSK identity
hint: None
SRP username:
None
TLS session
ticket lifetime hint: 86400 (seconds)
TLS session
ticket:
0000 - ac c5 55
91 29 bc 0f 5f-dd 4e e4 f2 2d 7d 56 5b ..U.).._.N..-}V[
0010 - 09 1d 91
b2 d1 a3 1a 26-ed e2 74 5e fb 9a fd a4 .......&..t^....
0020 - c3 af ed
15 4b 91 6d 68-70 94 59 90 ea f1 97 98 ....K.mhp.Y.....
0030 - 6b 3e 1c
3c 70 05 ab de-bc 5f 06 85 0a b4 fa 02 k>.<p...._......
0040 - 6f 2d db
14 52 3f 1f 00-60 69 dc fc 7c fd c7 f9 o-..R?..`i..|...
0050 - d2 97 5e
85 d1 1a b2 97-ba de 2e 0e 09 da 1d 78 ..^............x
0060 - 6a f5 f0
c7 e7 c1 f4 35-41 87 7f e1 4d 00 91 03 j......5A...M...
0070 - 50 5e 36
9b ad 20 fb 1e-72 61 86 0b b3 22 60 f6 P^6.. ..ra..."`.
0080 - 64 ef 89
9f 3e e2 34 fe-49 53 d4 1c 1c 4c 21 3f d...>.4.IS...L!?
0090 - 30 44 e4
a8 47 34 32 3e-b0 01 ff d8 af 36 db b9 0D..G42>.....6..
00a0 - 93 dd 45
8f 88 fe be bf-a5 4f 12 45 46 f2 56 3b ..E......O.EF.V;
00b0 - ad 59 e3
c7 f0 c1 ed de-f7 a9 86 e9 e5 1d 34 b3 .Y............4.
00c0 - e7 48 35
a2 c8 c1 fb 7d-a8 7a 10 9a e5 17 60 73 .H5....}.z....`s
Start Time:
1747847586
Timeout : 7200
(sec)
Verify return
code: 18 (self signed certificate)
Extended master
secret: no
Max Early Data:
0
---
read R BLOCK
---
Post-Handshake New
Session Ticket arrived:
SSL-Session:
Protocol :
TLSv1.3
Cipher :
TLS_AES_256_GCM_SHA384
Session-ID:
C080DB8AFDC904CC956381A1F69FBD007CB5A7C644F5DFC3D32A9274FFF8D401
Session-ID-ctx:
Resumption PSK:
D2CE869CCB046E4D7B418D37BCE3EED4A87AD1D4FEA520191D45CEFF6A6B52F3643BF6751B11D376A06EB4C87E4B0354
PSK identity:
None
PSK identity
hint: None
SRP username:
None
TLS session
ticket lifetime hint: 86400 (seconds)
TLS session
ticket:
0000 - ac c5 55
91 29 bc 0f 5f-dd 4e e4 f2 2d 7d 56 5b ..U.).._.N..-}V[
0010 - 55 26 f1
31 d4 7f 7b ee-c9 38 30 83 d9 61 c6 e2 U&.1..{..80..a..
0020 - 67 ca 9b
27 a1 52 74 ef-ba 3d da 54 df da 1c 39 g..'.Rt..=.T...9
0030 - 12 e7 4e
4b ba 66 44 d0-69 99 58 ab ad 49 27 73 ..NK.fD.i.X..I's
0040 - 8d 5b 84
82 19 1c c5 49-2a 68 35 2d 48 e4 6d 9a .[.....I*h5-H.m.
0050 - 57 d7 96
11 2b 5d 59 54-01 9d c6 3b 8c 0f 2d 40 W...+]YT...;..-@
0060 - c4 3e 00
7c 08 2a 38 7e-3e 7e 54 16 7c 11 22 ff .>.|.*8~>~T.|.".
0070 - ee f8 d6
ca f1 75 1e 7d-4a 81 da b2 87 c0 33 21 .....u.}J.....3!
0080 - b9 91 c6
c4 d5 b2 37 d2-c2 23 00 ca 67 8b 3c 8e ......7..#..g.<.
0090 - 8f 85 92
8e 52 a0 75 52-a8 85 ee 13 4f fd c7 e6 ....R.uR....O...
00a0 - 23 53 66
f6 38 35 ba 85-3a c7 8a 70 ae b6 fb 57 #Sf.85..:..p...W
00b0 - 59 88 0a
1f d6 6e 13 01-ae 80 59 89 40 38 e4 9b Y....n....Y.@8..
00c0 - a8 71 99
c0 98 f4 ff 9b-e2 84 9a f4 b1 c3 82 8a .q..............
Start Time:
1747847586
Timeout : 7200
(sec)
Verify return
code: 18 (self signed certificate)
Extended master
secret: no
Max Early Data:
0
---
read R BLOCK
closed
Sent using Zoho Mail
---- On Wed, 21 May 2025 07:19:06 -0500 Christopher Schultz
<ch...@christopherschultz.net> wrote ---
Alex,
On 5/19/25 5:37 PM, My Subs wrote:
> I'm using Ubuntu 20.04 with OpenSSL 1.1.1f.
Okay.
>> 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?
>
>
>
> I did change the connector configuration because when updating to Tomcat
> 10.1.40, I could no longer use class Http11AprProtocol on the protocol
> attribute (I learned then that the APR connector had been deprecated). So, I
> set it to "HTTP/1.1" to get automatic selection of the JSSE OpenSSL
> implementation.
>
>
>
> I also set certificateVerification="required" because I found in the logs an
> error message saying that "optional" does not work with HTTP/2.
>
>
>
> Besides, I'm now testing on Tomcat 11.0.6.
Okay.
>> 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?
>
>
>
> Actually, the configuration works seamlessly with client certificate
> verification for as long as no CRL verification is set up. Client
> certificates are accepted and made visible to servlets.
>
>
>
> However, as soon as I set on the <SSLHostConfig>, attribute
> certificateRevocationListFile to the CRL file, or
> certificateRevocationListPath to the directory containing the CRL file
> (properly c_rehashed), all client certificates are rejected.
When you have configured a CRL, are *all* requests rejected, or only
those which include a client certificate during the handshake? I see you
have configured certificateVerification="required" so maybe there are no
modes of operation where client certificates are used.
I'm trying to understand whether this is a problem with the whole setup
when CRLs are added, or only a problem when a client certificate is
actively being checked against the CRL.
>> 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?
>
>
>
> Since certificateVerification is now set to "required", it means that
> handshakes fail with client certs, and therefore, there is no access at all.
Does the connection actually hang, or do you simply get a failed (but
complete) handshake?
>> If you connect to your server like this, what does the output look like:
>
> $ openssl s_client -showcerts -connect https://host/whatever
>
>
>
> I get the following:
>
>
>
> CONNECTED(00000003)
>
> Can't use SSL_get_servername
>
> depth=0 CN = localhost
>
> verify error:num=18:self signed certificate
>
> verify return:1
>
> depth=0 CN = localhost
>
> verify return:1
>
> ---
>
> Certificate chain
>
> 0 s:CN = localhost
>
> i:CN = localhost
>
> -----BEGIN CERTIFICATE-----
>
> MIIBfzCCASWgAwIBAgIUBtGtuw6cAZvC560e0RVjnI/+tnwwCgYIKoZIzj0EAwIw
>
> FDESMBAGA1UEAwwJbG9jYWxob3N0MCAXDTI1MDQxNjIyNTg0OFoYDzIxMjUwMzIz
>
> MjI1ODQ4WjAUMRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjO
>
> PQMBBwNCAASWvdHleExdyTqn+wXgNY3XueCLjkkpbrtVhw8lB4DsmkTJDUCdszZX
>
> 9ElKT01bP10cX+mrinNNEtgKFPBwcTCXo1MwUTAdBgNVHQ4EFgQUJIQfq2nU9T2J
>
> uexYvw1bqosji6cwHwYDVR0jBBgwFoAUJIQfq2nU9T2JuexYvw1bqosji6cwDwYD
>
> VR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiAUmPONFAU4ThvidgLnlXiu
>
> 7XElAkAGfmlXKkN0DgJWwAIhAPkF8ngCXY4G7Y2obrGUS2u80p06O2ZYFtXyrM3+
>
> UuRN
>
> -----END CERTIFICATE-----
>
> ---
>
> Server certificate
>
> subject=CN = localhost
>
>
>
> issuer=CN = localhost
>
>
>
> ---
>
> No client certificate CA names sent
This looks like a problem. Do you have the trusted certificates
configured correctly? I would have expected Tomcat to send a list of
acceptable certificates back to the client. That's not strictly required
by the TLS spec, but it's handy for debugging like this.
If you do not configure the CRL, are any CA certs listed in this output?
I haven't used TLS with Tomcat much, so I'm not entirely sure what to
expect.
> Just to be clear, this is my current <Connector>:
>
>
>
> <Connector
>
> protocol="HTTP/1.1"
>
> port="8443"
>
> SSLEnabled="true"
>
> maxParameterCount="1000"
>
> >
>
> <SSLHostConfig
>
> protocols="TLSv1.3"
>
> certificateVerification="required"
>
> caCertificatePath="tls/client/certs-ca"
>
> certificateRevocationListPath="tls/client/crls"
>
> >
>
> <Certificate
>
> certificateKeyFile="tls/server/localhost-key.pem"
>
> certificateFile="tls/server/localhost-cert.pem"
>
> />
>
> </SSLHostConfig>
>
> <UpgradeProtocol
>
> className="org.apache.coyote.http2.Http2Protocol"
>
> />
>
> </Connector>
Thanks for posting the whole thing.
-chris
> ---- On Fri, 09 May 2025 13:46:35 -0500 Christopher Schultz
> <mailto:ch...@christopherschultz.net> wrote ---
>
>
>
> 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
>> <mailto:mailto:n82...@gmail.com> wrote ---
>>
>>
>>
>>
>>> On 2025 May 7, at 11:43, My Subs
>>> <mailto:mailto: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:mailto:mailto:users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail:
>> mailto:mailto:mailto:users-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: mailto:mailto:users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:mailto:users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: mailto:users-h...@tomcat.apache.org
