CRL verification broken?

2025-05-19 Thread My Subs 
Good morning,



Ten days ago, I wrote reporting that CRL verification is not working on Tomcat 
10.1.40.  But I have not heard back, since.  Is this feature expected to remain 
broken?  It is not working either on 11.0.6.



Thank you,



Alex

Sent using Zoho Mail












Hello Chuck, 
 
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. 
 
 
 
 
 
  
  
  
  
 
  
 
 
 
 
 
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? 
 
Thank you, 
 
Alex 
 
 
 
Sent using Zoho Mail 
 
 
 
 
 
 
 
 
 On Wed, 07 May 2025 12:37:16 -0500 Chuck Caldarale 
 wrote --- 
 
 
 
 
> On 2025 May 7, at 11:43, My Subs  
> 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: 
> 
> protocol="org.apache.coyote.http11.Http11AprProtocol" 
> port="8443" 
> SSLEnabled="true" 
> maxParameterCount="1000" 
> > 
> protocols="TLSv1.3" 
> certificateVerification="optional" 
> caCertificatePath="conf/ca-certs" 
> certificateRevocationListPath="conf/ca-crls" 
> > 
> certificateKeyFile="conf/localhost-ec-key.pem" 
> certificateFile="conf/localhost-ec-cert.pem" 
> /> 
> 
>  className="org.apache.coyote.http2.Http2Protocol" 
> /> 
> 
> 
> 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 , 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:users-unsubscr...@tomcat.apache.org 
For additional commands, e-mail: mailto:mailto:users-h...@tomcat.apache.org

Re: CRL verification broken?

2025-05-19 Thread Christopher Schultz 

Alex,

On 5/19/25 9:44 AM, My Subs wrote:

Ten days ago, I wrote reporting that CRL verification is not working
on Tomcat 10.1.40.  But I have not heard back, since.  Is this
feature expected to remain broken?  It is not working either on
11.0.6.

Did you see my reply?

-chris


Hello Chuck,
  
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.
  
  
  
  
  
  
 protocol="HTTP/1.1"
 port="8443"
 SSLEnabled="true"
 maxParameterCount="1000"
 >
  
  
  
 
  
  
  
  
  
  
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?
  
Thank you,
  
Alex
  
  
  
Sent using Zoho Mail
  
  
  
  
  
  
  
  
 On Wed, 07 May 2025 12:37:16 -0500 Chuck Caldarale  wrote ---
  
  
  
  

On 2025 May 7, at 11:43, My Subs  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:





 


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 , 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:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: mailto: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

Re: Adding a CRL to certificate client authentication causes connector to stop responding to all requests having a client certificate.

2025-05-19 Thread My Subs 
Hi Christopher,



I'm very sorry for not having seen your prompt reply.  Somehow, it ended up in 
the wrong mail folder.  My apologies.  Please find my responses below.



> It probably does not matter, but what OS are you using, and what version of 
> OpenSSL are you using?



I'm using Ubuntu 20.04 with OpenSSL 1.1.1f.



> 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.



> 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 , attribute 
certificateRevocationListFile to the CRL file, or certificateRevocationListPath 
to the directory containing the CRL file (properly c_rehashed), all client 
certificates are rejected.



> 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.



> 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(0003)

    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: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:ECDSA+SHA224:RSA+SHA224

    Shared Requested Signature Algorithms: 
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519: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 826 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)

    ---

    140001294333248:error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 
alert certificate required:../ssl/record/rec_layer_s3.c:1552:SSL alert number 
116





Just to be clear, this is my current :



    

    

    

    

    

    



Thanks again for your attention.



Alex










 On Fri, 09 May 2025 13:46:35 -0500 Christopher Schultz 
 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