Re: AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Christopher Schultz]

Thomas,

On 6/15/22 03:08, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,


-Ursprüngliche Nachricht-
Von: Pavan Kumar Tiruvaipati 
Gesendet: Mittwoch, 15. Juni 2022 08:59
An: Christopher Schultz 
Cc: Tomcat Users List 
Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

Hi,

Tomcat server started successfully.

I'm seeing the following error in the tomcat logs when SSL is enabled in
server.xml

Application is not able to run on https://localhost:8080.

2022-06-15 12:02:43,923 [http-3003-1] DEBUG
*org.apache.tomcat.util.net.JIoEndpoint
- Handshake failed*

*javax.net.ssl.SSLHandshakeException: no cipher suites in common at
sun.security.ssl.Alert.createSSLException(Unknown Source) *

*at sun.security.ssl.Alert.createSSLException(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) *

*at sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
known
Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
Source) at
sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
Source) at
sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.TransportContext.dispatch(Unknown Source) at
sun.security.ssl.SSLTransport.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
tory.java:233)
at
org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
01)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
at java.lang.Thread.run(Unknown Source)*

If I disable SSL in tomcat server.xml, It's working with Non-SSL (
http://localhost:8080).

Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
required to establish a handshake ?

Please let me know if you need more details.


Regards,
Pavan

On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Pavan,

Please reply to the list and not me personally.

On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:


maxSpareThreads="75"

 enableLookups="false" disableUploadTimeout="true"
 acceptCount="100"  scheme="https" secure="true"
connectionTimeout="2"
 clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
keystoreFile="conf/certificate" keystorePass="x"
useBodyEncodingForURI="true"
SSLEnabled="true"/>


That all looks pretty straightforward.

When you say it's "not working", can you be more specific? Does the
Tomcat server start? Are there any errors or warnings in the logs?

-chris


On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
mailto:ch...@christopherschultz.net>>

wrote:


 Pavan,

 On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
  > We have replaced JDK 1.8 with JRE 1.8.0_333.
  >
  > SSL configuration was working fine with Tomcat 6.0.45 before
 replacing JDK
  > with JRE.
  >
  > Now it's not working.
  >
  > In server.xml, SSL Protocol is set to "TLS".
  >
  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
  >
  > Are there any specific protocols / versions to be used to enable
 SSL ?

 Please post your  configuration. Remove any secrets
that

may

 be in there (e.g. passwords).

 -chris





The error says that the client and the server couldn’t find a common cipher 
suite.
They couldn’t agree on any cipher.
Does your keystore contain a valid private key?


The problem is likely that Tomcat 6 (which is ancient) defaults to TLSv1 
and no higher (this is a guess; I'm not bothering to look at a 
14-year-old version of Tomcat to figure out what the problem really is). 
The client isn't willing to connect to such an ancient version of any 
protocol, so it fails with the handshake failure.



Maybe you can try to print out all available cipher suites on your environment:
https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms
You can add the code to a jsp-page and print out the available algorithms.


Try explicitly setting the "enabled protocols" to "TLSv1, TLSv1.1, 
TLSv1.2, TLSv1.3" -- however that's done in that dinosaur of a Tomcat 
version. It might be enabledProtocols="..." if might be 
SSLProtocols="..." and it might have a lot to 

Re: AW: Filehandle left open when using sendfile

[Christopher Schultz]

Thomas,

On 6/15/22 02:26, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Christopher,


-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Dienstag, 14. Juni 2022 20:26
An: users@tomcat.apache.org
Betreff: Re: Filehandle left open when using sendfile

Thomas,

On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the

attribute "org.apache.tomcat.sendfile.filename".

Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is

still a file-handle on this file.

Which user? Some admin on the server, or the user using the browser?
(Dumb question, I know, but tb and ff had a bug for a while where
downloads would leave dangling file handles, disallowing deleting those files
after they were downloaded.)


I took a look at NioEndpoint.java -->


https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util

/net/NioEndpoint.java

At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);

However, there is no close in this method. Maybe this might cause the

open file-handle?

Did you read the line above that?

  @SuppressWarnings("resource") // Closed when channel is closed
  FileInputStream fis = new FileInputStream(f);

The channel itself is cleaned-up properly and, with it, the file handle.

https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226

(At least, I *think* this is where the cleanup happens. I'm not very well-
versed in the connection-handling code in Tomcat.)


We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I

think there are different implementations for sendfile-feature.

The open file-handle can be observer via ProcessExplorer from Microsoft.


How long did you wait for the file handle to close?

Are you able to attach a debugger and see that the object hasn't been
cleaned-up?

-chris



Thanks for taking a look at it.
Sorry, if the setup was not described in detail. Maybe you can imagine an image 
library, hosted server-side.
The user can upload pics and after upload the user can also decide to delete 
the image.


Light bulb: are you using ImageIO?

There have been some well-known leaks in there over the years. It's also 
*very* easy to leak file handles if you aren't managing your resources 
appropriately.


Are you *sure* you have clean use of resources within your own code?

If you are using *any* of Java's javax.imageio code, is it possible to 
skip that and re-try your test? Can you e.g. upload a plain text file 
(or even an image) and only stream the bytes from client -> disk without 
doing anything else?



Requests:
1) POST-Request with image upload. Server saves the image in the file system 
and returns the URL.
2) GET-Request, the browser requests the URL of the uploaded picture. Server is 
sending the file via sendfile
3) POST-Request with command to delete the picture (maybe user doesn’t like the 
pic). Tomcat tries to delete the file on the server side but fails because of 
the left handle in step 2


Are you sure it's from step #2 and not step #1?


The handle stays for several minutes for sure.

It is hard to debug because when stepping through, the file-handle is gone 
after processing the request.


That seems suspicious if you are saying that Tomcat is definitely 
leaving the file handle open.



I think there are some if-statements whether the transmission is pending or 
finished.
The mentioned line in the NIOEndpoint is not reached. So the file handle must 
be left somewhere else. My first assumption was wrong.


Does the problem go away if you disable sendfile and stream the file 
directly?


-chris

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

Re: cert/key config woes

[Rob Sargent]

Chris,
Back at my desk and going through you notes again.

On 6/14/22 14:43, Rob Sargent wrote:


Let's get one thing working at a time. I reviewed this thread, and I 
honestly can't figure out exactly what you are trying to do. Can you 
please clarify?


1. "I want to get Tomcat working as a server with a TLS 
Certificate." This can be self-signed, or it can be signed by a real 
Certificate Authority. The process is almost the same, except you 
have to send something to the CA.


2. "I want to get Tomcat working as a server with a TLS Certificate, 
AND I want to demand that all clients connecting also present a 
client-certificate to authenticate."


Which of the above is it?

I believe I can live with #1.  I'm using a self-signed cert for sure.


Okay, that's good because it reduces the complexity of this whole 
operation by ~50%.


Because the server-side cert is self-signed, it likely means that each 
client will have to import the server-cert into the /client/ 
trust-store. Either that, of you can "ignore warnings" but IMO that's 
a significant reduction in security. We can talk about that, later.





Your server should not have to configure a trust store, full stop.

It the moment it's name in the read-in properties file but not actually 
acted on in the code.  TODO!


You might not need it. You only need a trust store if you want 
option #2 from above.



The clients get them from command line -D properties

     defvs += F"
    -Djavax.net.ssl.keyStore=/ppr/certs/sgs10.0.2.118.p12
    -Djavax.net.ssl.keyStoreType=PKCS12
    -Djavax.net.ssl.keyStorePassword=changeit"
     defvs += F" -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
    -Djavax.net.ssl.trustStoreType=PKCS12
    -Djavax.net.ssl.trustStorePassword=changeit"

But as I said "It's working" so I'm likely to let sleeping dogs lie.


Okay, so if your clients (connecting you your Tomcat, right?) are 
using keystores, then... it sounds like you want option #2
My embedded tomcat is mainly there to mediate between db and analysis 
clients.  I just need the traffic between the two to be encrypted.


You mention 3 parties: HTTP clients, HTTP server (Tomcat), and db. 
Which links must be encrypted? (I would answer "all links should be 
encrypted", but encrypting between app <- -> db is a whole different 
process.)


I am under an edict to encrypt ALL traffic within my AWS set-up.  I have 
the tomcat-postgres using SSL (verify-full).  This is NOT a high traffic 
situation.


I'll re-re-read the rest of your message until I get it right.

Thanks ever so much.
rjs

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

Re: cert/key config woes

[Rob Sargent]

> On Jun 15, 2022, at 7:45 AM, Christopher Schultz 
>  wrote:
> 
> Rob,
> 
>> On 6/14/22 15:38, Rob Sargent wrote:
>> On 6/14/22 13:06, Christopher Schultz wrote:
>> Thanks so much for your perseverance.
> 
> No problem. Anything to avoid doing $work.

Away from my desk this morning but will retool accordingly asap

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

Re: cert/key config woes

[Christopher Schultz]

Rob,

On 6/14/22 15:38, Rob Sargent wrote:

On 6/14/22 13:06, Christopher Schultz wrote:

Thanks so much for your perseverance.


No problem. Anything to avoid doing $work.


On 6/14/22 14:43, Rob Sargent wrote:

Let's get one thing working at a time. I reviewed this thread, and I 
honestly can't figure out exactly what you are trying to do. Can you 
please clarify?


1. "I want to get Tomcat working as a server with a TLS Certificate." 
This can be self-signed, or it can be signed by a real Certificate 
Authority. The process is almost the same, except you have to send 
something to the CA.


2. "I want to get Tomcat working as a server with a TLS Certificate, 
AND I want to demand that all clients connecting also present a 
client-certificate to authenticate."


Which of the above is it?

I believe I can live with #1.  I'm using a self-signed cert for sure.


Okay, that's good because it reduces the complexity of this whole 
operation by ~50%.


Because the server-side cert is self-signed, it likely means that each 
client will have to import the server-cert into the /client/ 
trust-store. Either that, of you can "ignore warnings" but IMO that's a 
significant reduction in security. We can talk about that, later.


Your server should not have to configure a trust store, full stop.

and here we can see I don't actually use truststore so that puts 
the lie to have my claim.


You might not need it. You only need a trust store if you want option 
#2 from above.



The clients get them from command line -D properties

     defvs += F"
    -Djavax.net.ssl.keyStore=/ppr/certs/sgs10.0.2.118.p12
    -Djavax.net.ssl.keyStoreType=PKCS12
    -Djavax.net.ssl.keyStorePassword=changeit"
     defvs += F" -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
    -Djavax.net.ssl.trustStoreType=PKCS12
    -Djavax.net.ssl.trustStorePassword=changeit"

But as I said "It's working" so I'm likely to let sleeping dogs lie.


Okay, so if your clients (connecting you your Tomcat, right?) are 
using keystores, then... it sounds like you want option #2
My embedded tomcat is mainly there to mediate between db and analysis 
clients.  I just need the traffic between the two to be encrypted.


You mention 3 parties: HTTP clients, HTTP server (Tomcat), and db. Which 
links must be encrypted? (I would answer "all links should be 
encrypted", but encrypting between app <- -> db is a whole different 
process.)



Shortest route to that is all I'm after.
10.0.2.118 is the server and that's where I make my (one and only) 
self-signed cert.  That gets added to fullca.p12 (selfie + cacerts).


What is "cacerts" here? If it's self-signed, then you only need two 
things in the keystore: the key and the cert. Java's keytool will report 
this as "one entry" in the keystore with a single alias. It will say 
it's a "private key entry" and (somewhat surprisingly) give you a 
certificate for that entry if you do "keytool -list -v". I say 
"surprisingly" because private keys are NOT certificates. But keytool 
treats them as one thing because #reasons.



It all boils down to this:

1. Every pair of entities in a TLS connection are called "peers".

2. Any peer can choose to require the other one to authenticate.

3. In practice, servers *always* authenticate to the clients by 
presenting a certificate. It's up to the client to decide if the cert 
is acceptable. (This is where self-signed versus CA-signed comes into 
play. If you control the client, don't bother paying a CA a bunch of 
money for what copy/paste can solve for you.) The client maintains a 
trust store for this purpose.


The server manages this behind the scenes using a key store. A trust 
store is not required, because this part doesn't require clients to 
authenticate to servers.


(Technically, Java calls these things KeyStores no matter what. A 
"trust store" is just a KeyStore used for trust. Don't let that 
confuse you. I will always refer to a file-containing-a-key-and-cert 
as a "key store" and a 
file-containing-a-bunch-of-certificates-to-be-trusted as a "trust store.)


4. In public, clients almost never authenticate themselves. So you 
only need to deal with the "server part". If you want the server to 
authenticate the client, then you just flip everything backwards and 
layer it on top of what you already had:


  4a. Server needs a trust tore, filled with the certs from the clients
  4b. Clients each need a key store, containing the client's key+cert

That's pretty much it.



That helps a lot.  Basically I had the responsibilities reversed.  I 
have a couple of other configuration annoyances to fix and will clean 
"stores" as well.


You should only need the embedded equivalent of this:


  

  


I would recommend setting:

- honorCipherOrder="true" on the SSLHostConfig
- protocols="TLSv1.2,TLSv1.3" (or whatever the highest you can get away 
with is)

- I used a .p12 file in . JKS files are a PITA; don't use them.

You may need to set:

- 

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Pavan,

which client are you using to access Tomcat?
Which TLS-Version are activated on that client?

Java 8 ships with ssl ciphers suitable for common browsers (in default 
configuration).

If the server is public, use https://www.ssllabs.com/ssltest/ to check the 
server ciphers.
If the server is not public, you can use e.g. https://github.com/rbsec/sslscan 
You need to check the ciphers of the server and which ciphers are enabled on 
the client side.

I would also recommend to upgrade Tomcat because it is an ancient version and 
reached EOL many years ago.

Greetings, Thomas

> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 11:14
> An: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Java ships cipher suites. We have printed all available cipher suites in our
> environment.
> 
> Tomcat is not able to enable SSL with JRE 1.8.0_333.
> 
> The error says that the client and the server couldn’t find a common cipher
> suite.
> 
> 1. Which cipher suite to be updated in tomcat to enable SSL ?
> 2. Where do we need to update the cipher suite in tomcat ? server.xml ?
> 
> Please advise me if there is any other way to fix the SSL issue. Thank you in
> advance.
> 
> Regards,
> Pavan
> 
> On Wed, Jun 15, 2022 at 1:34 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> > Java already ships with a broad variety of cipher suites.
> > The crypto providers are listed in the file java.security.
> > As long as you don’t modify this file, SSL should work just fine in
> > the default java-configuration.
> >
> > Greetings, Thomas
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Pavan Kumar Tiruvaipati 
> > > Gesendet: Mittwoch, 15. Juni 2022 09:56
> > > An: thomas.hoffm...@speed4trade.com.invalid
> > > Cc: Tomcat Users List 
> > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > >
> > > Hi,
> > >
> > > Thanks for the quick response. I will print all the available cipher
> > suites.
> > >
> > > Where do I need to update the cipher to support SSL ?
> > >
> > >
> > > Regards,
> > > Pavan
> > >
> > > On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade
> GmbH)
> > >  wrote:
> > >
> > > > Hello,
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Pavan Kumar Tiruvaipati 
> > > > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > > > An: Christopher Schultz 
> > > > > Cc: Tomcat Users List 
> > > > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > > > >
> > > > > Hi,
> > > > >
> > > > > Tomcat server started successfully.
> > > > >
> > > > > I'm seeing the following error in the tomcat logs when SSL is
> > > > > enabled in server.xml
> > > > >
> > > > > Application is not able to run on https://localhost:8080.
> > > > >
> > > > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > > > *org.apache.tomcat.util.net.JIoEndpoint
> > > > > - Handshake failed*
> > > > >
> > > > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > > > > at sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > > > >
> > > > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > > > >
> > > > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipher
> > > > > Suit
> > > > > e(Un
> > > > > known
> > > > > Source) at
> > > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unkn
> > > > > own
> > > > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source)
> > > > > at
> > > > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unkn
> > > > > own
> > > > > Source) at
> > > > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(U
> > > > > nkno
> > > > > wn
> > > > > Source) at
> > > > > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > > > > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source)
> > > > > at sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > > > > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > > > > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > > > > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown
> > > > > Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
> > > > > Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
> > > > > Source) at org.apache.tomcat.util.net
> > > > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > > > > tory.java:233)
> > > > > at
> > > > > org.apache.tomcat.util.net
> > > > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > > > > 01)
> > > > > at org.apache.tomcat.util.net
> > > > 

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Java ships cipher suites. We have printed all available cipher suites in
our environment.

Tomcat is not able to enable SSL with JRE 1.8.0_333.

The error says that the client and the server couldn’t find a common cipher
suite.

1. Which cipher suite to be updated in tomcat to enable SSL ?
2. Where do we need to update the cipher suite in tomcat ? server.xml ?

Please advise me if there is any other way to fix the SSL issue. Thank you
in advance.

Regards,
Pavan

On Wed, Jun 15, 2022 at 1:34 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
> Java already ships with a broad variety of cipher suites.
> The crypto providers are listed in the file java.security.
> As long as you don’t modify this file, SSL should work just fine in the
> default java-configuration.
>
> Greetings, Thomas
>
>
> > -Ursprüngliche Nachricht-
> > Von: Pavan Kumar Tiruvaipati 
> > Gesendet: Mittwoch, 15. Juni 2022 09:56
> > An: thomas.hoffm...@speed4trade.com.invalid
> > Cc: Tomcat Users List 
> > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> >
> > Hi,
> >
> > Thanks for the quick response. I will print all the available cipher
> suites.
> >
> > Where do I need to update the cipher to support SSL ?
> >
> >
> > Regards,
> > Pavan
> >
> > On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
> >  wrote:
> >
> > > Hello,
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Pavan Kumar Tiruvaipati 
> > > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > > An: Christopher Schultz 
> > > > Cc: Tomcat Users List 
> > > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > > >
> > > > Hi,
> > > >
> > > > Tomcat server started successfully.
> > > >
> > > > I'm seeing the following error in the tomcat logs when SSL is
> > > > enabled in server.xml
> > > >
> > > > Application is not able to run on https://localhost:8080.
> > > >
> > > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > > *org.apache.tomcat.util.net.JIoEndpoint
> > > > - Handshake failed*
> > > >
> > > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > > > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > > >
> > > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > > >
> > > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuit
> > > > e(Un
> > > > known
> > > > Source) at
> > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > > > Source) at
> > > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unkno
> > > > wn
> > > > Source) at
> > > > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > > > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > > > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
> > > > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > > org.apache.tomcat.util.net
> > > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > > > tory.java:233)
> > > > at
> > > > org.apache.tomcat.util.net
> > > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > > > 01)
> > > > at org.apache.tomcat.util.net
> > > .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > > > at java.lang.Thread.run(Unknown Source)*
> > > >
> > > > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > > > http://localhost:8080).
> > > >
> > > > Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any
> > > > changes required to establish a handshake ?
> > > >
> > > > Please let me know if you need more details.
> > > >
> > > >
> > > > Regards,
> > > > Pavan
> > > >
> > > > On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > > > ch...@christopherschultz.net> wrote:
> > > >
> > > > > Pavan,
> > > > >
> > > > > Please reply to the list and not me personally.
> > > > >
> > > > > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > > > > >  > > > > > maxThreads="150" minSpareThreads="25"
> > > > > maxSpareThreads="75"
> > > > > > enableLookups="false" disableUploadTimeout="true"
> > > > > > acceptCount="100"  scheme="https" secure="true"
> > > > > > connectionTimeout="2"
> > > > > > clientAuth="false" 

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
Java already ships with a broad variety of cipher suites.
The crypto providers are listed in the file java.security.
As long as you don’t modify this file, SSL should work just fine in the default 
java-configuration.

Greetings, Thomas


> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 09:56
> An: thomas.hoffm...@speed4trade.com.invalid
> Cc: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Thanks for the quick response. I will print all the available cipher suites.
> 
> Where do I need to update the cipher to support SSL ?
> 
> 
> Regards,
> Pavan
> 
> On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Pavan Kumar Tiruvaipati 
> > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > An: Christopher Schultz 
> > > Cc: Tomcat Users List 
> > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > >
> > > Hi,
> > >
> > > Tomcat server started successfully.
> > >
> > > I'm seeing the following error in the tomcat logs when SSL is
> > > enabled in server.xml
> > >
> > > Application is not able to run on https://localhost:8080.
> > >
> > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > *org.apache.tomcat.util.net.JIoEndpoint
> > > - Handshake failed*
> > >
> > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > >
> > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > >
> > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuit
> > > e(Un
> > > known
> > > Source) at
> > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > > Source) at
> > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unkno
> > > wn
> > > Source) at
> > > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
> > > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > org.apache.tomcat.util.net
> > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > > tory.java:233)
> > > at
> > > org.apache.tomcat.util.net
> > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > > 01)
> > > at org.apache.tomcat.util.net
> > .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > > at java.lang.Thread.run(Unknown Source)*
> > >
> > > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > > http://localhost:8080).
> > >
> > > Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any
> > > changes required to establish a handshake ?
> > >
> > > Please let me know if you need more details.
> > >
> > >
> > > Regards,
> > > Pavan
> > >
> > > On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >
> > > > Pavan,
> > > >
> > > > Please reply to the list and not me personally.
> > > >
> > > > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > > > >  > > > > maxThreads="150" minSpareThreads="25"
> > > > maxSpareThreads="75"
> > > > > enableLookups="false" disableUploadTimeout="true"
> > > > > acceptCount="100"  scheme="https" secure="true"
> > > > > connectionTimeout="2"
> > > > > clientAuth="false" algorithm="SunX509"
> > sslProtocol="TLS"
> > > > >keystoreFile="conf/certificate" keystorePass="x"
> > > > > useBodyEncodingForURI="true"
> > > > >SSLEnabled="true"/>
> > > >
> > > > That all looks pretty straightforward.
> > > >
> > > > When you say it's "not working", can you be more specific? Does
> > > > the Tomcat server start? Are there any errors or warnings in the logs?
> > > >
> > > > -chris
> > > >
> > > > > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > > > >  > > > > >
> > > > wrote:
> > > > >
> > > > > Pavan,
> > > > >
> > > > > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> > > > >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> > > > >  >
> > > > >  > SSL configuration 

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Thanks for the quick response. I will print all the available cipher
suites.

Where do I need to update the cipher to support SSL ?


Regards,
Pavan

On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Pavan Kumar Tiruvaipati 
> > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > An: Christopher Schultz 
> > Cc: Tomcat Users List 
> > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> >
> > Hi,
> >
> > Tomcat server started successfully.
> >
> > I'm seeing the following error in the tomcat logs when SSL is enabled in
> > server.xml
> >
> > Application is not able to run on https://localhost:8080.
> >
> > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > *org.apache.tomcat.util.net.JIoEndpoint
> > - Handshake failed*
> >
> > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> >
> > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> >
> > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
> > known
> > Source) at
> > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > Source) at
> > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
> > Source) at
> > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > org.apache.tomcat.util.net
> .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > tory.java:233)
> > at
> > org.apache.tomcat.util.net
> .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > 01)
> > at org.apache.tomcat.util.net
> .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > at java.lang.Thread.run(Unknown Source)*
> >
> > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > http://localhost:8080).
> >
> > Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
> > required to establish a handshake ?
> >
> > Please let me know if you need more details.
> >
> >
> > Regards,
> > Pavan
> >
> > On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Pavan,
> > >
> > > Please reply to the list and not me personally.
> > >
> > > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > > >  > > > maxThreads="150" minSpareThreads="25"
> > > maxSpareThreads="75"
> > > > enableLookups="false" disableUploadTimeout="true"
> > > > acceptCount="100"  scheme="https" secure="true"
> > > > connectionTimeout="2"
> > > > clientAuth="false" algorithm="SunX509"
> sslProtocol="TLS"
> > > >keystoreFile="conf/certificate" keystorePass="x"
> > > > useBodyEncodingForURI="true"
> > > >SSLEnabled="true"/>
> > >
> > > That all looks pretty straightforward.
> > >
> > > When you say it's "not working", can you be more specific? Does the
> > > Tomcat server start? Are there any errors or warnings in the logs?
> > >
> > > -chris
> > >
> > > > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > > > mailto:ch...@christopherschultz.net>>
> > > wrote:
> > > >
> > > > Pavan,
> > > >
> > > > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> > > >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> > > >  >
> > > >  > SSL configuration was working fine with Tomcat 6.0.45 before
> > > > replacing JDK
> > > >  > with JRE.
> > > >  >
> > > >  > Now it's not working.
> > > >  >
> > > >  > In server.xml, SSL Protocol is set to "TLS".
> > > >  >
> > > >  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
> > > >  >
> > > >  > Are there any specific protocols / versions to be used to
> enable
> > > > SSL ?
> > > >
> > > > Please post your  configuration. Remove any secrets
> > > > that
> > > may
> > > > be in there (e.g. passwords).
> > > >
> > > > -chris
> > > >
> > >
>
> The error says that the client and the server couldn’t find a common
> cipher suite.
> They couldn’t agree on any cipher.
> Does your keystore contain a 

AW: Filehandle left open when using sendfile

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Gesendet: Mittwoch, 15. Juni 2022 08:26
> An: Tomcat Users List 
> Betreff: AW: Filehandle left open when using sendfile
> 
> Hello Christopher,
> 
> > -Ursprüngliche Nachricht-
> > Von: Christopher Schultz 
> > Gesendet: Dienstag, 14. Juni 2022 20:26
> > An: users@tomcat.apache.org
> > Betreff: Re: Filehandle left open when using sendfile
> >
> > Thomas,
> >
> > On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > > Hello,
> > > we are using Tomcat 10.0.16 under windows.
> > > For sending files to the browser, we are using sendfile by setting
> > > the
> > attribute "org.apache.tomcat.sendfile.filename".
> > > Streaming an image to the browser works well in this way.
> > > But we observed that if the user tries to delete the file
> > > afterwards, there is
> > still a file-handle on this file.
> >
> > Which user? Some admin on the server, or the user using the browser?
> > (Dumb question, I know, but tb and ff had a bug for a while where
> > downloads would leave dangling file handles, disallowing deleting
> > those files after they were downloaded.)
> >
> > > I took a look at NioEndpoint.java -->
> > >
> >
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util
> > > /net/NioEndpoint.java
> > >
> > > At line 869 there is a stream opened:
> > > FileInputStream fis = new FileInputStream(f);
> > >
> > > However, there is no close in this method. Maybe this might cause
> > > the
> > open file-handle?
> >
> > Did you read the line above that?
> >
> >  @SuppressWarnings("resource") // Closed when channel is closed
> >  FileInputStream fis = new FileInputStream(f);
> >
> > The channel itself is cleaned-up properly and, with it, the file handle.
> >
> >
> https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
> > aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
> >
> > (At least, I *think* this is where the cleanup happens. I'm not very
> > well- versed in the connection-handling code in Tomcat.)
> >
> > > We are using protocol="org.apache.coyote.http11.Http11NioProtocol"..
> > > I
> > think there are different implementations for sendfile-feature.
> > > The open file-handle can be observer via ProcessExplorer from Microsoft.
> >
> > How long did you wait for the file handle to close?
> >
> > Are you able to attach a debugger and see that the object hasn't been
> > cleaned-up?
> >
> > -chris
> >
> 
> Thanks for taking a look at it.
> Sorry, if the setup was not described in detail. Maybe you can imagine an
> image library, hosted server-side.
> The user can upload pics and after upload the user can also decide to delete
> the image.
> 
> Requests:
> 1) POST-Request with image upload. Server saves the image in the file
> system and returns the URL.
> 2) GET-Request, the browser requests the URL of the uploaded picture.
> Server is sending the file via sendfile
> 3) POST-Request with command to delete the picture (maybe user doesn’t
> like the pic). Tomcat tries to delete the file on the server side but fails
> because of the left handle in step 2
> 
> The handle stays for several minutes for sure.
> 
> It is hard to debug because when stepping through, the file-handle is gone
> after processing the request.
> I think there are some if-statements whether the transmission is pending or
> finished.
> The mentioned line in the NIOEndpoint is not reached. So the file handle
> must be left somewhere else. My first assumption was wrong.
> 
> Greetings, Thomas

Short update on this issue:
Today, I could further debug the issue.

Within Http2AsyncUpgradeHandler.java the following code creates the file handle:

protected SendfileState processSendfile(SendfileData sendfile) {
if (sendfile != null) {
try {
try (FileChannel channel = FileChannel.open(sendfile.path, 
StandardOpenOption.READ)) {
sendfile.mappedBuffer = channel.map(MapMode.READ_ONLY, 
sendfile.pos, sendfile.end - sendfile.pos);
}
..

Even with the try-with-resource block, the file handle is still there after 
this code block.
Sometimes the handle vanishes quite quickly, sometimes the handle stays open 
for many minutes.

It can be verified with a  little jsp sample page:
<%@page import="java.io.*"%>
<%@page import="java.net.*"%>
<%@page import="org.apache.coyote.Constants"%>
<%
String fileName = "c:\\temp\\test.png";
File file = new File(fileName);
long l = file.length();
request.setAttribute(Constants.SENDFILE_FILENAME_ATTR, 
file.getAbsolutePath());
request.setAttribute(Constants.SENDFILE_FILE_START_ATTR, 0L);
request.setAttribute(Constants.SENDFILE_FILE_END_ATTR, l);
response.setHeader("Content-Length", Long.toString(l));
String contentType = URLConnection.guessContentTypeFromName(fileName);
if (contentType == null)
{
contentType = "application/octet-stream";
}

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 08:59
> An: Christopher Schultz 
> Cc: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Tomcat server started successfully.
> 
> I'm seeing the following error in the tomcat logs when SSL is enabled in
> server.xml
> 
> Application is not able to run on https://localhost:8080.
> 
> 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> *org.apache.tomcat.util.net.JIoEndpoint
> - Handshake failed*
> 
> *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> sun.security.ssl.Alert.createSSLException(Unknown Source) *
> 
> *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> sun.security.ssl.TransportContext.fatal(Unknown Source) *
> 
> *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> sun.security.ssl.TransportContext.fatal(Unknown Source) at
> sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
> known
> Source) at
> sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> Source) at
> sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
> Source) at
> sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> sun.security.ssl.SSLTransport.decode(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
> tory.java:233)
> at
> org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> 01)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> at java.lang.Thread.run(Unknown Source)*
> 
> If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> http://localhost:8080).
> 
> Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
> required to establish a handshake ?
> 
> Please let me know if you need more details.
> 
> 
> Regards,
> Pavan
> 
> On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> > Pavan,
> >
> > Please reply to the list and not me personally.
> >
> > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > >  > > maxThreads="150" minSpareThreads="25"
> > maxSpareThreads="75"
> > > enableLookups="false" disableUploadTimeout="true"
> > > acceptCount="100"  scheme="https" secure="true"
> > > connectionTimeout="2"
> > > clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
> > >keystoreFile="conf/certificate" keystorePass="x"
> > > useBodyEncodingForURI="true"
> > >SSLEnabled="true"/>
> >
> > That all looks pretty straightforward.
> >
> > When you say it's "not working", can you be more specific? Does the
> > Tomcat server start? Are there any errors or warnings in the logs?
> >
> > -chris
> >
> > > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > > mailto:ch...@christopherschultz.net>>
> > wrote:
> > >
> > > Pavan,
> > >
> > > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> > >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> > >  >
> > >  > SSL configuration was working fine with Tomcat 6.0.45 before
> > > replacing JDK
> > >  > with JRE.
> > >  >
> > >  > Now it's not working.
> > >  >
> > >  > In server.xml, SSL Protocol is set to "TLS".
> > >  >
> > >  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
> > >  >
> > >  > Are there any specific protocols / versions to be used to enable
> > > SSL ?
> > >
> > > Please post your  configuration. Remove any secrets
> > > that
> > may
> > > be in there (e.g. passwords).
> > >
> > > -chris
> > >
> >

The error says that the client and the server couldn’t find a common cipher 
suite.
They couldn’t agree on any cipher.
Does your keystore contain a valid private key?

Maybe you can try to print out all available cipher suites on your environment:
https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms
You can add the code to a jsp-page and print out the available algorithms.

Greetings,
Thomas

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

Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

[Pavan Kumar Tiruvaipati]

Hi,

Tomcat server started successfully.

I'm seeing the following error in the tomcat logs when SSL is enabled in
server.xml

Application is not able to run on https://localhost:8080.

2022-06-15 12:02:43,923 [http-3003-1] DEBUG
*org.apache.tomcat.util.net.JIoEndpoint
- Handshake failed*

*javax.net.ssl.SSLHandshakeException: no cipher suites in common at
sun.security.ssl.Alert.createSSLException(Unknown Source) *

*at sun.security.ssl.Alert.createSSLException(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) *

*at sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.TransportContext.fatal(Unknown Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Unknown
Source) at
sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown Source)
at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown Source)
at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
Source) at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
sun.security.ssl.TransportContext.dispatch(Unknown Source) at
sun.security.ssl.SSLTransport.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:233)
at
org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:701)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
at java.lang.Thread.run(Unknown Source)*

If I disable SSL in tomcat server.xml, It's working with Non-SSL (
http://localhost:8080).

Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
required to establish a handshake ?

Please let me know if you need more details.


Regards,
Pavan

On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Pavan,
>
> Please reply to the list and not me personally.
>
> On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> >  > maxThreads="150" minSpareThreads="25"
> maxSpareThreads="75"
> > enableLookups="false" disableUploadTimeout="true"
> > acceptCount="100"  scheme="https" secure="true"
> > connectionTimeout="2"
> > clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
> >keystoreFile="conf/certificate" keystorePass="x"
> > useBodyEncodingForURI="true"
> >SSLEnabled="true"/>
>
> That all looks pretty straightforward.
>
> When you say it's "not working", can you be more specific? Does the
> Tomcat server start? Are there any errors or warnings in the logs?
>
> -chris
>
> > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > mailto:ch...@christopherschultz.net>>
> wrote:
> >
> > Pavan,
> >
> > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> >  >
> >  > SSL configuration was working fine with Tomcat 6.0.45 before
> > replacing JDK
> >  > with JRE.
> >  >
> >  > Now it's not working.
> >  >
> >  > In server.xml, SSL Protocol is set to "TLS".
> >  >
> >  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
> >  >
> >  > Are there any specific protocols / versions to be used to enable
> > SSL ?
> >
> > Please post your  configuration. Remove any secrets that
> may
> > be in there (e.g. passwords).
> >
> > -chris
> >
>

AW: Filehandle left open when using sendfile

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Christopher,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Dienstag, 14. Juni 2022 20:26
> An: users@tomcat.apache.org
> Betreff: Re: Filehandle left open when using sendfile
> 
> Thomas,
> 
> On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello,
> > we are using Tomcat 10.0.16 under windows.
> > For sending files to the browser, we are using sendfile by setting the
> attribute "org.apache.tomcat.sendfile.filename".
> > Streaming an image to the browser works well in this way.
> > But we observed that if the user tries to delete the file afterwards, there 
> > is
> still a file-handle on this file.
> 
> Which user? Some admin on the server, or the user using the browser?
> (Dumb question, I know, but tb and ff had a bug for a while where
> downloads would leave dangling file handles, disallowing deleting those files
> after they were downloaded.)
> 
> > I took a look at NioEndpoint.java -->
> >
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util
> > /net/NioEndpoint.java
> >
> > At line 869 there is a stream opened:
> > FileInputStream fis = new FileInputStream(f);
> >
> > However, there is no close in this method. Maybe this might cause the
> open file-handle?
> 
> Did you read the line above that?
> 
>  @SuppressWarnings("resource") // Closed when channel is closed
>  FileInputStream fis = new FileInputStream(f);
> 
> The channel itself is cleaned-up properly and, with it, the file handle.
> 
> https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
> aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
> 
> (At least, I *think* this is where the cleanup happens. I'm not very well-
> versed in the connection-handling code in Tomcat.)
> 
> > We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I
> think there are different implementations for sendfile-feature.
> > The open file-handle can be observer via ProcessExplorer from Microsoft.
> 
> How long did you wait for the file handle to close?
> 
> Are you able to attach a debugger and see that the object hasn't been
> cleaned-up?
> 
> -chris
> 

Thanks for taking a look at it.
Sorry, if the setup was not described in detail. Maybe you can imagine an image 
library, hosted server-side.
The user can upload pics and after upload the user can also decide to delete 
the image.

Requests:
1) POST-Request with image upload. Server saves the image in the file system 
and returns the URL.
2) GET-Request, the browser requests the URL of the uploaded picture. Server is 
sending the file via sendfile
3) POST-Request with command to delete the picture (maybe user doesn’t like the 
pic). Tomcat tries to delete the file on the server side but fails because of 
the left handle in step 2

The handle stays for several minutes for sure.

It is hard to debug because when stepping through, the file-handle is gone 
after processing the request.
I think there are some if-statements whether the transmission is pending or 
finished.
The mentioned line in the NIOEndpoint is not reached. So the file handle must 
be left somewhere else. My first assumption was wrong.

Greetings, Thomas