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

[My Subs]

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

Re: Null Byte Injection?

[Christopher Schultz]

James,

On 5/9/25 1:49 PM, James H. H. Lampert wrote:

On 5/9/25 10:21 AM, Christopher Schultz wrote:
. . .
A lot of this comes from the fact that Tomcat is written in Java which 
does not use null-terminated strings. A null byte in a string in Java 
is not special in any way, and so it can't be used to prematurely 
terminate a string that should otherwise be considered to be longer.

. . .

Hope that helps,
-chris


It does.

Given that Tomcat is in Java, and our webapp context (and presumably any 
other webapp context that will run in Tomcat) is in Java, and null- 
terminated strings are not a Java-native format, it sounds like the most 
a null byte injection could do would be to (as Dr. McCoy once put it) 
"take up knitting."


And if a rogue null byte somehow got past the webapp, and into the C 
layer of the server for which our Tomcat webapp acts as a front-end, the 
worst it could do would be to cause a child-server job to either abend 
or lock up, which would be at most a minor nusiance.


I would indeed be slightly worried about the C layer of your server.

Is the C layer relatively small and/or has a small-ish interface exposed 
to your Tomcat-hosted application? It's shockingly easy to check for 
potentially poisonous null-bytes in Java strings before handing anything 
off to the C layer that may be more error-prone.


So you can either have the C programmers review all their code (which I 
would encourage) and/or you could have your Java programmers ensure 
nothing potentially-nasty gets passed into the C code. Belt and suspenders.


-chris


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

[Christopher Schultz]

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?



 


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?



 
 
 

 


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  
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: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: use

Null Byte Injection?

[James H. H. Lampert]

Ladies and Gentlemen:

One of the customers whose Tomcat installation we manage brought up the 
possible threat of null byte injection.


Is there anything within Tomcat itself that can mitigate this?

Or is it purely something I need to take up with our webapp people?

--
JHHL

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

Re: Skip resource path in TLD scanner?

[Jakub Królikowski]

On Thu, May 8, 2025 at 6:04 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Jakub,
>
> On 5/7/25 3:26 PM, Jakub Królikowski wrote:
> > 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?
>
> Looks like you just mention the class in your JarScanner element (which
> probably doesn't exist, so you will have to add configuration to change
> from the defaults).
>
> https://tomcat.apache.org/tomcat-9.0-doc/config/jar-scanner.html
>
> > 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.
>
> The above documentation shows that JarScanning is already completely
> pluggable.
>
> There is also
> https://tomcat.apache.org/tomcat-9.0-doc/config/jar-scan-filter.html
>
> -chris
>

Hi Christopher,

JarScanning indeed is completely pluggable and I successfully configured it
in my context.xml file.
However, TldScanner does something more, as far as I understand. TldScanner
scans all subfolders in WEB-INF, jars with JarScanner are scanned at the
end. It's hardcoded in org.apache.jasper.servlet.TldScanner:

 public void scan() throws IOException, SAXException {
 scanPlatform();
  scanJspConfig();
  *scanResourcePaths(WEB_INF);*
  scanJars();
  }


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

-- 
Jakub Królikowski
+49 162 6400341

Re: Null Byte Injection?

[Christopher Schultz]

James,

On 5/9/25 11:43 AM, James H. H. Lampert wrote:
One of the customers whose Tomcat installation we manage brought up the 
possible threat of null byte injection.


Is there anything within Tomcat itself that can mitigate this?

Or is it purely something I need to take up with our webapp people?


I guess that depends upon what you are primarily worried about.

Null byte injection can be used to attack all kinds of things that 
aren't careful about such things.


Tomcat primarily cares about things like HTTP headers and URLs and such. 
In all of those cases, injecting a null-byte ends up causing mismatches 
of things like header names and URL patterns, so generally you are not 
exposed to any issues such as path-traversal or security-constraint 
bypasses.


A lot of this comes from the fact that Tomcat is written in Java which 
does not use null-terminated strings. A null byte in a string in Java is 
not special in any way, and so it can't be used to prematurely terminate 
a string that should otherwise be considered to be longer.


You may have downstream data storage or programs that are susceptible to 
null-byte injection, and Tomcat itself can't really help with that. You 
could use something like a Web Application Firewall to inspect all your 
traffic looking for such things, but just remember that any document you 
upload to a web application is very likely to have null bytes in it, and 
they are usually perfectly innocent. So "rejecting any request 
containing a null byte" is heavy-handed and usually breaks things.


Hope that helps,
-chris


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

Re: Null Byte Injection?

[James H. H. Lampert]

On 5/9/25 10:21 AM, Christopher Schultz wrote:
. . .
A lot of this comes from the fact that Tomcat is written in Java which 
does not use null-terminated strings. A null byte in a string in Java is 
not special in any way, and so it can't be used to prematurely terminate 
a string that should otherwise be considered to be longer.

. . .

Hope that helps,
-chris


It does.

Given that Tomcat is in Java, and our webapp context (and presumably any 
other webapp context that will run in Tomcat) is in Java, and 
null-terminated strings are not a Java-native format, it sounds like the 
most a null byte injection could do would be to (as Dr. McCoy once put 
it) "take up knitting."


And if a rogue null byte somehow got past the webapp, and into the C 
layer of the server for which our Tomcat webapp acts as a front-end, the 
worst it could do would be to cause a child-server job to either abend 
or lock up, which would be at most a minor nusiance.


Thanks.

--
JHHL

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

Re: Null Byte Injection?

[James H. H. Lampert]

On 5/9/25 11:37 AM, Christopher Schultz wrote:


So you can either have the C programmers review all their code (which
I would encourage) and/or you could have your Java programmers ensure
nothing potentially-nasty gets passed into the C code. Belt and
suspenders.


I *am* "the C programmers," and I'm almost certain that there is nothing 
in the C layer that expects nulls in the incoming data stream (which 
uses a proprietary protocol that, as I recall, requires packets to 
declare their byte-counts) to terminate strings, or indeed, to hold any 
special significance whatsoever.


And most of the real work in that server is done in RPG, which, when it 
uses variable-length strings at all, prepends them with lengths.


--
JHHL


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