Re: Adding a CRL to certificate client authentication causes connector to stop responding to all requests having a client certificate.
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Adding a CRL to certificate client authentication causes connector to stop responding to all requests having a client certificate.
Hello,
I'm setting up certificate client authentication on Tomcat 10.0.0
running on Java 16+36. 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.
Re: Skip resource path in TLD scanner?
On Sat, Apr 29, 2017 at 12:01 PM Mark Thomas wrote: > On 28/04/17 17:00, Matt Cosentino wrote: > > Yes, it's other folders within WEB-INF. I turned on the TldScanner > > logging and it is definitely what is causing the delay. My situation > > probably isn't very typical. The delay varies in my various web > > applications, the worst being about 20 seconds. It all adds up > > though, and every second counts when our sites are down. > > There is a solution available but it is intended more for the embedded > use case rather than a standard Tomcat install. Using it in a standard > install would require (effectively) patching Tomcat. > > The general idea would be to use the TldPreScanned class. That does > require all the TLDs to be listed in advance. On the plus side, no > scanning delay. On the down side, adding TLDs requires code changes. > Doing this with a standard Tomcat install requires changes to the > JasperInitializer (hence the patch). I don't think there is a pure > config way around that but I'll look into it. > > A better solution would probably be to make it easier to plugin in a > custom TLDScanner - i.e. purely with config. If you'd like us to explore > this option we should re-open 61052 and adjust accordingly. I don't > think there is enough demand for filtering resource paths to make that > worth implementing. > > One final thought. Are you running the web application from a WAR or an > expanded directory? (The latter would be faster). > > Mark > Hello, I reorganized the code of my web app and I moved all views (mainly .jsp files) to WEB-INF/view folder. This means that the WEB-INF/view folder is scanned recursively for TLD files. And it takes some time... I am very interested in using the TldPreScanned class, which I see has been implemented. How can it be used? I think it would be very useful to have a feature in the Tomcat configuration to specify a custom class for scanning TLDs or to skip specific folders from WEB-INF from scanning. Best regards, Jakub > > > > > - Matt > > > > > > -Original Message- From: Mark Thomas > > [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28 AM To: > > Tomcat Users List Subject: Re: Skip > > resource path in TLD scanner? > > > > On 27/04/17 23:39, Matt Cosentino wrote: > >> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html > >> > >> There is one for skipping jar files: > >> > >> tomcat.util.scan.StandardJarScanFilter.jarsToSkip > > > > > > > >> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check > >> any property to skip user defined paths. > > > > Is it other paths within WEB-INF you need to skip? > > > > When I read "skipping resource paths" I was thinking of skipping the > > various places where Tomcat treat directories as JARs that then get > > scanned for TLDs (which can be configured via the JarScanner). But it > > sounds like skipping those won't help you. > > > > How sure are you that it is checking the directories below WEB-INF > > that is the cause of the delay? That isn't a typical source of > > start-up delay although it is certainly possible. > > > > Finally, what sort of delay are we talking out here? Seconds? > > Minutes? > > > > Mark > > > > > >> -Original Message- From: Mark Thomas > >> [mailto:ma...@apache.org] Sent: Thursday, April 27, 2017 5:05 PM > >> To: Tomcat Users List Subject: Re: Skip > >> resource path in TLD scanner? > >> > >> On 27/04/17 21:17, Matt Cosentino wrote: > >>> I need to skip some of the resource paths within WEB-INF. I know > >>> there's a property for skipping jar files, but I couldn't find > >>> one for resource paths. I reported this as a bug and was told > >>> that the property exists. Where is it? > >> > >> Where have you looked? > >> > >> 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 > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Jakub Królikowski +49 162 6400341
