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/21/25 9:01 PM, My Subs wrote:

Chris,




Is the client sending just their own cert, or also the chain?

It would
  be unusual for the client to send a chain, but instead
just sends their
  own leaf certificate. I'm assuming that both
the root and the
  intermediate / subordinate cert are both in
the trust store. Is that
  correct?


The client is
sending both the leaf and the intermediate certificates (both are in
the PKCS12 file imported into Firefox).  That's the only way for the
chain of trust to work, because only the root certificate is in the
trust store (well, that's how it's supposed to be, as far as I
understand).  And it works fine until the CRL comes into play.



I also tested adding
the subordinate CA's certificate to the trust store.  No change.
With no CRL configured, works alright; but when it is configured, I
get the same errors.  Revoked client cert is rejected as such, and
valid client cert is rejected with SSL_ERROR_UNKNOWN_CA_ALERT.





Can

you please try one more thing for me?
  
  > Can

you create a self-signed certificate, and use ONLY that self-signed
  certificate in your trust store, and have the client send that
to the
  server?
  
  > It will be easier

for me if I just have to deal with a single cert on
  either side
of the connection rather than set up a whole signing
  authority,
etc. before I'm able to reproduce it.
  



Done.  Removed root CA certificate from trust store, and left only a
self-signed certificate.  The result is exactly the same.  With no
CRL checking, it works fine.  Add CRL checking, and I get: "Peer
does not recognize and trust the CA that issued your certificate.
Error code: SSL_ERROR_UNKNOWN_CA_ALERT"


Perfect. That will make it a lot easier for me to duplicate your setup.


Guess the finger
increasingly points to the CRL checking code.


Agreed, at least in theory.

-chris


 On Wed, 21 May 2025 16:29:10 -0500 Christopher Schultz 
 wrote ---



Alex,
  
On 5/21/25 1:26 PM, My Subs wrote:

To test this, I set
certificateRevocationListPath to the directory having the CRL file;
changed to certificateVerification="optional"; and
downgraded to HTTP 1.1 (as mentioned, "optional" does not
work with HTTP 2).  The result is that requests without a client
certificate get a 200 OK response.
  
Good.
  

However, *all* requests having a client certificate (valid or
revoked) are rejected.
  
Okay.
  

If the client certificate is revoked, it is correctly identified as
such.  Firefox displays message "SSL peer rejected your
certificate as revoked.  Error code: SSL_ERROR_REVOKED_CERT_ALERT".
  
Good!
  

If the client certificate is not revoked, the connection fails with
Firefox displaying an unexpected message: "Peer does not
recognize and trust the CA that issued your certificate.  Error code:
SSL_ERROR_UNKNOWN_CA_ALERT".
  
Obviously, not good.
  
But I wonder if this is a problem with adding the CRL (which looks like

it's working) versus the trust store. But...
  

But that same issuing CA is perfectly recognized when the
certificateRevocationListPath attribute is removed from the
connector.

Yeah, I was afraid you'd say that.
  

Requests with a non-revoked client certificate get a 200 OK
response, and that certificate is made visible to servlets as a
java.security.cert.X509Certificate object. This holds both for
"optional" and> "required" verification.

  > > It's CRL checking what triggers the error.


I'm
not sure whether the message "No client certificate
CA names sent" means a problem with the trust store.  As you can
see from my connector, caCertificatePath is set to the trust store directory. It
contains the certificate of the root CA, which signed the certificate
of the subordinate CA.  The client certificates used in the above
test are signed by that subordinate CA.  And as
shown, those are correctly verified when no CRL is configured.
  
Is the client sending just their own cert, or also the chain? It would

be unusual for the client to send a chain, but instead just sends their
own leaf certificate. I'm assuming that both the root and the
intermediate / subordinate cert are both in the trust store. Is that
correct?
  

   > If you do not configure the CRL, are any CA certs listed in
this output?

No.  Message "No client certificate CA names sent" is still there.
The full output is:

  > > [snip]
  >

---

No client certificate CA names sent
  
Okay.
  
Sounds like it's time for me to try to reproduce this.
  
Can you please try one more thing for me?
  
Can you create a self-signed certificate, and use ONLY that self-signed

certificate in your trust store, and have the client send that to the
server?
  
It will be easier for me if I just have to deal with a single cert on

either side of the connection rather than set up a whole signing
authority, etc. before I'm able to reproduce it.
  
-chris
  

 On Wed, 21 May 2025 07:19:06 -0500 Christopher Schultz 
 wrote ---



Alex,

On 5/19/25 

Re: Apache Tomcat 9 SAML Setup With Active Directory

[Christopher Schultz]

William,

On 4/9/25 11:09 AM, William Crowell wrote:

Is there any current up-to-date documentation on how to setup Apache
Tomcat 9 with SAML and Active Directory that is not AI generated?

I know you can do Keycloak IdP with Tomcat, but I was trying to
avoid setting up an identity provider.

I am finding links, but I think there is some missing information on
how-to.


I'm sorry I didn't see then when you originally posted it, but Tomcat
has no support for SAML at all in its core capabilities. You may be able 
to get some kind of add-on to support it.


At $work, we have built our own single-legged SAML support that does 
work with AD/ADFS and other SAML providers. (It's single-legged in that 
the first message we get is the "SAML response" so the IdP generates its 
own SSO request, signs the response, and sends that through the client 
to our service.) It's not rocket science, you just parse and validate 
the response document against a trusted certificate store and then do 
whatever you want.


Something that Tomcat doesn't have is the ability for an application to 
just say "this is the user, pretend they just logged-in". So to support 
SAML in Tomcat yourself, you'll likely have to implement it at least 
partially as a Valve in order to get access to the internals necessary 
to shove the user Principal into the right place(s).


I've been considering writing a Passkeys implementation for Tomcat and 
something SAML-related could dovetail nicely with that. As yet I haven't 
been able to dedicate enough time to wrap my head around JASPI... er, 
Jakarta Authentication to understand the best way to implement such 
pluggable authentication modules into Tomcat in the cleanest way.


-chris

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

Re: Tcnative-2 PQC support

[Mark Thomas]

On 22/05/2025 07:53, Mark Thomas wrote:

On 21/05/2025 23:04, federico bustamante wrote:
Yes, I don't have high hopes on make in it work on Ubuntu, but I 
thought of

giving it a try using mingw-64.
I'll report back.


I've been building the Tomcat Native binaries for Windows for a while. 
I'll try with 3.5 and report back.


This won't work with the currently documented Tomcat Native build 
process for Windows.


I'm working on some updates.

I'll also start a discussion on dev@ about switching the convenience 
builds to use OpenSSL 3.5 since that is the new LTS version.


Looks like we are heading towards consensus to do that - assuming I can 
get the build working.


Mark



Mark



Fede

On Wed, May 21, 2025, 18:20 Christopher Schultz <
ch...@christopherschultz.net> wrote:


Federico,

On 5/21/25 2:22 PM, federico bustamante wrote:
I've only tried with OpenSSL 3.5, but I suspect it's the same story 
with

older versions (which, to be honest, wouldn't bother me as much as it

being

a specific problem with 3.5).


I'll try reproducing the build process on Windows. We know the build CAN
be produced on Windows, because, well... we produce convenience binaries
for Windows with each tcnative release. But there may be some
environmental nuances that aren't completely documented in our build
process. We should fix that if it's the case.


I'll try building the DLL on Ubuntu.


Strictly speaking, this is not possible. You may be able to build a
Linux binary, but creating a Windows DLL on Linux would require that you
set up a toolchain that is much more complicated than just doing it on
Windows in the first place.

-chris


On Wed, May 21, 2025, 13:35 Christopher Schultz <
ch...@christopherschultz.net> wrote:


Federico,

On 5/21/25 12:27 PM, Christopher Schultz wrote:

Federico,

On 5/21/25 10:58 AM, federico bustamante wrote:

Hi!
Did anyone have any luck building tcnative-2.dll with Openssl 3.5 to

add

Post Quantum Cryptography support?
I tried following the steps in the wiki, but didn't have any luck

(tried

with cmake and nmake).


Have you been able to compile tcnative-2.dll with earlier versions of
OpenSSL? I'm asking to see if you are having trouble with building
tcnative in general, or if OpenSSL 3.5 is what is causing the 
problem.


FYI I just tried building libtcnative on MacOS against OpenSSL 3.5 and
the build was successful. I believe the build process for Windows 
is ...

complex compared to *NIX-style builds.

But I wanted to confirm that tcnative didn't have any issues with
building against OpenSSL 3.5 in general, and that seems not to be the

case.


So the problem must be with the Windows build process itself.

-chris


-
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




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

RE: WebSocket session is never closed

[Harri Pesonen]

Thanks, will change it to this:

Session.close(new CloseReason(CLOSED_ABNORMALLY, "IOE on write"))

The problem happened when we updated Tomcat, meaning that all existing 
WebSocket connections were closed.
Then after Tomcat restart, the client apparently reconnected, but this 
reconnect was disconnected within a second by the client.
Or does this error mean that it was closed by the server?

java.io.IOException: An established connection was aborted by the software in 
your host machine

This problem happened only with this one connection, while there were several 
other connections which did not have any problems.

-Harri

-Original Message-
From: Mark Thomas  
Sent: torstai 22. toukokuuta 2025 9.50
To: users@tomcat.apache.org
Subject: Re: WebSocket session is never closed

On 21/05/2025 10:37, Harri Pesonen wrote:
> Hello,
> 
> We have a random problem with Apache Tomcat/9.0.100 in Windows, JDK 11.0.13.
> We have seen this problem only once so far.
> Problem is that WebSocket connection is apparently closed but there is no 
> callback to @OnClose handler, which is implemented in @ServerEndpoint class.

That shouldn't happen. If you ever figure out what triggers this issue, do let 
us know. There might be an edge case we need to fix in the error handling.



> I just implemented possible workaround for this problem by calling close() on 
> the WebSocket when this IOException happens in the sendText() callback.
> Now I am asking, do you think that this workaround will fix the problem, if 
> it ever happens again?

It should do yes. You might want to call:

Session.close(new CloseReason(CLOSED_ABNORMALLY, "IOE on write"))

rather than

Session.close()

to signal to Tomcat that the session is being closed due to an error condition. 
It should step additional error events being triggered. But both methods should 
work.

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: Tcnative-2 PQC support

[federico bustamante]

I couldn't make it work with mingw64.
The switch to 3.5 LTS would be wonderful, I hope you can get the build
working, Mark.
Please keep us updated.

Thanks,
Fede.

On Thu, May 22, 2025, 07:07 Mark Thomas  wrote:

> On 22/05/2025 07:53, Mark Thomas wrote:
> > On 21/05/2025 23:04, federico bustamante wrote:
> >> Yes, I don't have high hopes on make in it work on Ubuntu, but I
> >> thought of
> >> giving it a try using mingw-64.
> >> I'll report back.
> >
> > I've been building the Tomcat Native binaries for Windows for a while.
> > I'll try with 3.5 and report back.
>
> This won't work with the currently documented Tomcat Native build
> process for Windows
> I'm working on some updates.
>
> > I'll also start a discussion on dev@ about switching the convenience
> > builds to use OpenSSL 3.5 since that is the new LTS version.
>
> Looks like we are heading towards consensus to do that - assuming I can
> get the build working.
>
> Mark
>
> >
> > Mark
> >
> >>
> >> Fede
> >>
> >> On Wed, May 21, 2025, 18:20 Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >>> Federico,
> >>>
> >>> On 5/21/25 2:22 PM, federico bustamante wrote:
>  I've only tried with OpenSSL 3.5, but I suspect it's the same story
>  with
>  older versions (which, to be honest, wouldn't bother me as much as it
> >>> being
>  a specific problem with 3.5).
> >>>
> >>> I'll try reproducing the build process on Windows. We know the build
> CAN
> >>> be produced on Windows, because, well... we produce convenience
> binaries
> >>> for Windows with each tcnative release. But there may be some
> >>> environmental nuances that aren't completely documented in our build
> >>> process. We should fix that if it's the case.
> >>>
>  I'll try building the DLL on Ubuntu.
> >>>
> >>> Strictly speaking, this is not possible. You may be able to build a
> >>> Linux binary, but creating a Windows DLL on Linux would require that
> you
> >>> set up a toolchain that is much more complicated than just doing it on
> >>> Windows in the first place.
> >>>
> >>> -chris
> >>>
>  On Wed, May 21, 2025, 13:35 Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
> > Federico,
> >
> > On 5/21/25 12:27 PM, Christopher Schultz wrote:
> >> Federico,
> >>
> >> On 5/21/25 10:58 AM, federico bustamante wrote:
> >>> Hi!
> >>> Did anyone have any luck building tcnative-2.dll with Openssl 3.5
> to
> >>> add
> >>> Post Quantum Cryptography support?
> >>> I tried following the steps in the wiki, but didn't have any luck
> >>> (tried
> >>> with cmake and nmake).
> >>
> >> Have you been able to compile tcnative-2.dll with earlier versions
> of
> >> OpenSSL? I'm asking to see if you are having trouble with building
> >> tcnative in general, or if OpenSSL 3.5 is what is causing the
> >> problem.
> >
> > FYI I just tried building libtcnative on MacOS against OpenSSL 3.5
> and
> > the build was successful. I believe the build process for Windows
> > is ...
> > complex compared to *NIX-style builds.
> >
> > But I wanted to confirm that tcnative didn't have any issues with
> > building against OpenSSL 3.5 in general, and that seems not to be the
> >>> case.
> >
> > So the problem must be with the Windows build process itself.
> >
> > -chris
> >
> >
> > -
> > 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
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>