Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-18 Thread Justin Y 

Hi Mark --

  Ha!  I just ran a test (while you were responding) and made the same 
confirmation:  TLSCertificateReloadListener in 10.1.18 works, 
TLSCertificateReloadListener in 10.1.19 doesn't.


  Thank you!  Happy to confirm 10.1.20 for you; just ask.  And, by the 
way, I've seen 'markt' showing up in those Changelogs for quite some 
time and it's a genuine pleasure to have a conversation with you.  
You've contributed so much to the Tomcat world, and I appreciate what 
you do.


-- Justin

On 3/18/24 3:20 PM, Mark Thomas wrote:

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into 
the source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Never mind. I've just confirmed that those changes did trigger a 
regression. I'll commit a fix shortly and it will be in the next round 
of releases.


Mark




Mark



   I'm using the /TLSCertificateReloadListener/ 
 
to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are 
used forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null 
out the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be 
loaded unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and 
key files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
 
implementation but have found no clear way to null the SSLContext of 
the (determined expired) SSLHostConfigCertificate objects to allow a 
reload.


   I appreciate any suggestions!

-- Justin



-
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


--
--

Justin Y 


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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-18 Thread Mark Thomas 

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into the 
source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Never mind. I've just confirmed that those changes did trigger a 
regression. I'll commit a fix shortly and it will be in the next round 
of releases.


Mark




Mark



   I'm using the /TLSCertificateReloadListener/ 
 to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are used 
forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null out 
the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be 
loaded unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and key 
files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
 implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.


   I appreciate any suggestions!

-- Justin



-
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

Memory leak in EncodingDetector?

2024-03-18 Thread Simon Niederberger 
Hi

I'm analyzing a memory leak reported by Tomcat, and have narrowed it
down to org.apache.jasper.compiler.EncodingDetector:

private static final XMLInputFactory XML_INPUT_FACTORY;
static {
XML_INPUT_FACTORY = XMLInputFactory.newInstance();
}

This class is called by webapp code on a GET request

at 
org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
at 
org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
at 
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
at 
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
...
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

The EncodingDetector class, if not yet loaded, will be loaded in the
common classloader, then continue by loading the XMLInputFactory using
the webapp context, and might end up with a XMLInputFactory
implementation from a webapp-provided JAR. If that happens, the webapp
can't undeploy. (In my case, woodstox WstxInputFactory registers
itself as ServiceProvider for XMLInputFactory)

For completeness: javax.xml.stream.FactoryFinder.findServiceProvider()
is called without classloader (cl = null), and has

if (cl == null) {
//the current thread's context class loader
serviceLoader = ServiceLoader.load(type);
} else {
serviceLoader = ServiceLoader.load(type, cl);
}

I can't find anything online about memory leaks from webapp-provided
XMLInputFactory implementations, but this must be fairly common. Is my
understanding correct, or have I mis-configured something? (I'm mainly
wondering whether any XMLInputFactory-implementing JARs belong in
tomcat/lib, but again I'm not finding anything online confirming that)

Tomcat 10.1.19
JVM 17.0.10+7-Ubuntu-120.04.1
Ubuntu 20.04.6 LTS



Simon

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

Re: problems with partitioned cookies

2024-03-18 Thread Mark Thomas 

On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default 
partitioned attribute wasn't added until 9.0.85.


Mark

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

problems with partitioned cookies

2024-03-18 Thread info . asf 


Hi there,

I have to make my webapp complying to CHIPS. For this I am
trying to configure the CookieProcessor to allow partitioned cookies.

For this I added a CookieProcessor directive to the context.xml
like this:



However tomcat complains about this with
[Catalina-utility-1] org.apache.tomcat.util.digester.SetPropertiesRule.begin 
Match [Context/CookieProcessor] failed to set property [partitioned] to [true]

What am I doing wrong here? (Tomcat 9.0.82)

Regards,

  Holger

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

Re: Regression in mutual authentication in 9.0.86+?

2024-03-18 Thread Mark Thomas 
I've just tested 9.0.x and mutual TLS authentication appears to be 
working as expected.


I suggest starting with testing a simple JSP that echoes that attribute 
and if you still see the issue, provide us with your configuration. Note 
that the issue may be related to the certs you are using so the 
configuration information should include steps to recreate the TLS certs 
with keystore, OpenSSL or similar.


On 15/03/2024 00:48, Amit Pande wrote:

Hello all,

I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87 
too).

Some of our tests which involve on mutual authentication ("certificateVerification = 
optional") have started to fail.

In tests where the client does pass the certificate, I didn't see any SSL handshake 
errors (with SSL handshake debugging enabled) but 
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the 
attribute the application needs for further validations.


Have you confirmed that the certificate was sent from the client?


Could anyone please give pointers on how to debug this further?

Any code pointers where Tomcat sets this 
"javax.servlet.request.X509Certificate" attribute?


git clone
grep


Also, one more question - with optional certificate verification, the 
connection doesn't fail if certificate is not passed. But connection will fail 
if SSL handshake fails when a certificate is passed by client, is that correct 
understanding?


Yes, that is what I would expect.

Mark

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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-18 Thread Mark Thomas 

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into the 
source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Mark



   I'm using the /TLSCertificateReloadListener/ 
 to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are used 
forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null out 
the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be loaded 
unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and key 
files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
 implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.


   I appreciate any suggestions!

-- Justin



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