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

[Ivano Luberti]

Could there be a regression also in 9.0.86

Because I had a similar issue (reload tls didn't work) but It was the 
first time I was doing that on that tomcat instance and I  had assumed 
there was some misconfiguration, even though certificates where server 
correctly but the wrong expiration date and after restarting tomcat the 
certificates were served with correct dates


Il 18/03/2024 21:20, Mark Thomas ha scritto:

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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: problems with partitioned cookies

[info . asf]

Hi Mark,

dang! I missed that while checking the changelog.
Thanks for pointing out.

Regards,
  Holger

Mark Thomas wrote (at 2024-03-18 17:03 +):
> 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
>
>

-
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

[Mark Thomas]

On 19/03/2024 07:54, Ivano Luberti wrote:

Could there be a regression also in 9.0.86


Yes. It will be fixed in 9.0.88.

Mark



Because I had a similar issue (reload tls didn't work) but It was the 
first time I was doing that on that tomcat instance and I  had assumed 
there was some misconfiguration, even though certificates where server 
correctly but the wrong expiration date and after restarting tomcat the 
certificates were served with correct dates


Il 18/03/2024 21:20, Mark Thomas ha scritto:

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



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

Re: Memory leak in EncodingDetector?

[Christopher Schultz]

Simon,

On 3/18/24 15:17, Simon Niederberger wrote:

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


I'm not sure how many web applications ship with an XMLInputSource, but 
they definitely do exist. I'm fairly sure most applications won't set a 
system property or ship with a stax.properties/jaxp.properties file to 
override the default implementation, but of course if it's possible, 
someone will eventually do it.


I'm curious: in your example, how are you declaring your implementation 
class, and which implementation are you using?


Are you able to log in EncodingDetector. what the value of the 
thread's context classloader is? I would expect that it's using the 
common classloader, as you say, and that the implementation class would 
also be loaded using that same classloader.


-chris

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

Re: problems with partitioned cookies

[Christopher Schultz]

Holger,

On 3/19/24 04:46, info@klawitter.de wrote:

dang! I missed that while checking the changelog.
Thanks for pointing out.


I'm curious about CHIPS. It's still considered experimental and, 
honestly, every web browser on the planet is poised to use the 
equivalent of "partitioned cookies" for every site, everywhere, 
regardless of the "partitioned" flag on a Set-Cookie header.


Why do you have to bother modifying your application? It seems to be 
that CHIPS will die on the vine and will never become an official standard.


In fact, it looks like it has already died:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

https://datatracker.ietf.org/doc/html/draft-cutler-httpbis-partitioned-cookies 
[ "About This Document" -> "Latest Revision of this draft" -> 404 ]


Nobody has touched the spec on GitHub in 2 years: 
https://github.com/explainers-by-googlers/CHIPS-spec


... though this documentation has been updated as recently as 5 months 
ago: https://github.com/privacycg/CHIPS


-chris


Mark Thomas wrote (at 2024-03-18 17:03 +):

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




-
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

RE: [EXT]Re: 404 for j_security_check

[Rick Noel]

Chris,

Thanks for the help, I agree with all your statements.

I now see the  JSESSIONID cookies.

I found a bug in my code. My issue was nothing to do with Tomcat behavior.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Christopher Schultz  
Sent: Sunday, March 17, 2024 10:57 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/15/24 13:49, Rick Noel wrote:
>
> I really only want auth once
>
> All hits to jsp pages after a successful login do not trigger the Auth 
> process again.
>
> But hits to java action class servlets do trigger the Auth process
>
> Its  like session data is being lost for some pages but not for others

Can you watch the HTTP headers for your interaction to see what's happening? 
The browser should be sending JSESSIONID cookies with each request. If the 
server isn't sending any Set-Cookie header, the browser should leave things as 
they are.

Please note that Tomcat will send Set-Cookie when a session is created (by 
default, every JSP will create a session IIRC if you declare it to use 
sessions), plus Tomcat will rotate the session identifier as part of the 
authentication process. If you have code on the client that is storing the 
session and using it later, if your session id is being updated during 
authentication you need to make sure it gets updated everywhere the client is 
using it.

> I was thinking maybe this is reason..
>
> The Expires header specifies when content will expire, or how long content is 
> "fresh."
> After this time, the Portal Server will always check back with the remote 
> server to see if the content has changed.
> Most Web servers allow setting an absolute time to expire, a time 
> based on the last time that the client saw the object (last access time), or 
> a time based on the last time the document changed on your server (last 
> modification time).
>
> In JSP, we can set caching to forever using the Expires header like 
> so.
>
> response.setDateHeader("Expires",Long.MAX_VALUE)
>
> BUT I do not want to change my application code, I just want to tell 
> Tomcat 10 to stop Expiring cache so that session log in data is not 
> lost

No, the cache here refers to the client's resource (e.g. page, image,
etc.) cache. It has nothing to do with what's happening on the server.

> My main question is
> I want to know how to configure Tomcat 10 to not loose session data 
> that tells the user has successfully logged in

Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking 
it probably won't matter, but it's best practice to always do that to ensure 
your URLs are generated properly.

-chris

> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, March 15, 2024 12:19 PM
> To: users@tomcat.apache.org
> Subject: [EXT]Re: 404 for j_security_check
>
> [You don't often get email from ch...@christopherschultz.net. Learn 
> why this is important at https://aka.ms/LearnAboutSenderIdentification 
> ]
>
> Rick,
>
> On 3/14/24 15:37, Rick Noel wrote:
>> After moving from tomcat 9 to tomcat 10 after a user successfully 
>> logs in and then hits a restricted page, the login page is hit again 
>> but on this second login hit I get 404 page not found
> This is actually expected, since j_security_check is only supposed to be used 
> when the container (Tomcat) interrupts a user workflow to request 
> authentication.
>
>> How do I set the correct path in my  login jsp so that 
>> j_security_check is found?
>>
>> BTW  I actually am wondering why a  successful logged on user would 
>> even be sent to the log in page again?
> That's more of a question for your application than anything else.
>
>> My login page  is ->   /membership/login.jsp
>>
>> Here is how I set the path to  j_security_check in above login.jsp
>>
>> 
>>
>> My restricted  web.xml snippet
>
> Are you doing what I call a "direct login" where you have a "login page"
> that most users hit first. Like from example.com/app/ where there is no 
> initial request for a protected resource? Or are your users always (1) 
> requesting a protected resource then (2) Tomcat requests authentication then 
> (3) the user is forwarded to the resource originally requested in (1)?
>
>> 
>> 
>> External
>> /external/*
>> 
>> 
>> radiovoodoo
>> 
>> 
>> NONE
>> 
>> 
>> 
>> 
>> Auth
>> /auth/*
>> 
>> 
>> radiovoodoo
>> 
>> 
>> NONE
>> 
>> 
>> 
>> FORM
>> 
>> /membership/login.jsp
>> /membership/error.jsp
>> 
>> 
>
> Those NONE lines look weird to me. 
> Why are you explicitly specifying those? What part of your configuration 
> actually requests authentication and authorization?
>
> -chris
>
> -
> To unsubsc

PKCS#8 encryption algorithm unrecognized

[Timothy Resh]

where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?

Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds

Re: [EXT]Re: 404 for j_security_check

[Christopher Schultz]

Rick,

On 3/19/24 12:58, Rick Noel wrote:

Thanks for the help, I agree with all your statements.

I now see the  JSESSIONID cookies.

I found a bug in my code. My issue was nothing to do with Tomcat behavior.


Sorry for you, but glad it wasn't us :)

-chris


-Original Message-
From: Christopher Schultz 
Sent: Sunday, March 17, 2024 10:57 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Rick,

On 3/15/24 13:49, Rick Noel wrote:


I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others


Can you watch the HTTP headers for your interaction to see what's happening? 
The browser should be sending JSESSIONID cookies with each request. If the 
server isn't sending any Set-Cookie header, the browser should leave things as 
they are.

Please note that Tomcat will send Set-Cookie when a session is created (by 
default, every JSP will create a session IIRC if you declare it to use 
sessions), plus Tomcat will rotate the session identifier as part of the 
authentication process. If you have code on the client that is storing the 
session and using it later, if your session id is being updated during 
authentication you need to make sure it gets updated everywhere the client is 
using it.


I was thinking maybe this is reason..

The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time
based on the last time that the client saw the object (last access time), or a 
time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell
Tomcat 10 to stop Expiring cache so that session log in data is not
lost


No, the cache here refers to the client's resource (e.g. page, image,
etc.) cache. It has nothing to do with what's happening on the server.


My main question is
I want to know how to configure Tomcat 10 to not loose session data
that tells the user has successfully logged in


Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking 
it probably won't matter, but it's best practice to always do that to ensure 
your URLs are generated properly.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

[You don't often get email from ch...@christopherschultz.net. Learn
why this is important at https://aka.ms/LearnAboutSenderIdentification
]

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully
logs in and then hits a restricted page, the login page is hit again
but on this second login hit I get 404 page not found

This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.


How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration actually requests 
authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless 

Re: PKCS#8 encryption algorithm unrecognized

[Christopher Schultz]

Timothy,

On 3/19/24 14:18, Timothy Resh wrote:





where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below.


Is it possible for you to re-test with Tomcat 9.0.85 or later?

-chris

I have read some of the

https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?

Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds



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

Re: PKCS#8 encryption algorithm unrecognized

[Mark Thomas]

On 19/03/2024 18:18, Timothy Resh wrote:





where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?


Please provide a set of OpenSSL commands that create a problematic, 
self-signed certificate for localhost. This will save us a *lot* of time.


Mark




Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds



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

What future plans are for Tomcat authentication

[Mircea Butmalai]

Hello,


I am asking this questions on Tomcat Users mail list in order to find answers 
about how users and developers of Tomcat see the topic I am discribing.

In jakarta EE there is work for Jakarta Authentication (that reached 3.1 in 
development) formely JASPIC which Tomcat has implementation for it and Jakarta 
Authorization that I don's see Tomcat has implementation for it (maybe future 
plans).

Tomcat does at this point authentication / authorization as stated by Jakarta 
Servlet specification and Jakarta Authentication with custom mechanism provided 
by packages org.apache.catalina.authentication and org.apache.catalina.realm.

The standards Jakarta Authentication + Jakarta Authorization seems a different 
approach than Jakarta Servlet.

I found in Jakarta Authentication standart the following statement in Chapter 
1.1.2 Authentication Contexts:
An authentication context is responsible for constructing, initializing, and 
coordinating the invocation
of one or more encapsulated authentication modules. If the context 
implementation supports the
configuration of multiple authentication modules within a context (for example, 
as sufficient
alternatives), the context coordinates the invocation of the authentication 
modules on behalf of both
the message processing runtime and the authentication modules

but later I found this statement in Chapter 1.1.7 Authentication Exchanges and 
State
This version of this specification does not define the interfaces by which 
runtimes present correlation
facilities to authentication modules

in other words somebody is thinking about correlating multiple authentication 
modules on the same user request but standardisation effort did not reach 
detail phase on this problem.

I was forced on a project I am working to combine SPNEGO authenticator (from 
Tomcat) with FORM authenticator.
I found that it is not easy to to.
There were a lot of scenarios to be taken into consideration if one is willing 
to implement this combination.

I belive that other combinations are interesting like
HTTP DIGEST + SPNEGO + FORM
SSL + SPNEGO + HTTP DIGEST + FORM
ETC.

These combinations are not easy to implement since they involve a HTTP 
CHALLENGE that the browser + user may not be able to fullfill and you may be 
forced running into a final backup solution with FORM authenticator without any 
challange.

As I see in Tomcat if you have a Jakarta Authentication provider configured 
then that provider becomes the first option for authentication and any 
 web.xml element becomes ignored (any traditional Jakarta Servlet 
method).
I see here a conflict that has been introduced by Jakarta Authentication and 
jakarta Servlet specifications.

Questions are:

  1.  Is Jakarta Authentication specification going to replace the 
authentication part of Jakarta Servlet specification?
  2.  Are current authenticatiors from Tomcat (FORM, SPNEGO, SSL, HTTP DIGEST, 
HTTP BASIC, SSO) going to be implemented as Jakarta Authentication providers in 
future versions of Tomcat?
  3.  Is any effort to introduce in Jakarta standards + Tomcat an authentcator 
of type 2FA?


Thanks,
Marian Mircea Butmalai