On Thu, 16 Jun 2022 at 04:42, Christopher Schultz < ch...@christopherschultz.net> wrote:
> Thomas, > > On 6/15/22 03:08, Thomas Hoffmann (Speed4Trade GmbH) wrote: > > Hello, > > > >> -----Ursprüngliche Nachricht----- > >> Von: Pavan Kumar Tiruvaipati <ptiruvaip...@gmail.com> > >> Gesendet: Mittwoch, 15. Juni 2022 08:59 > >> An: Christopher Schultz <ch...@christopherschultz.net> > >> Cc: Tomcat Users List <users@tomcat.apache.org> > >> 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: > >>>> <Connector port="8080" > >>>> maxThreads="150" minSpareThreads="25" > >>> maxSpareThreads="75" > >>>> enableLookups="false" disableUploadTimeout="true" > >>>> acceptCount="100" scheme="https" secure="true" > >>>> connectionTimeout="20000" > >>>> clientAuth="false" algorithm="SunX509" > sslProtocol="TLS" > >>>> keystoreFile="conf/certificate" keystorePass="xxxxx" > >>>> 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 > >>>> <ch...@christopherschultz.net <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 <Connector> 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 do with whether or not > APR/native is being used, too. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Could this be an issue with the java jdk security disabled algorithms. Later versions of jdk 8 disabled TLSv1 and TLSv1.1 by default, and you have to change the jre/jdk conf/security/java.security file to fix it for older use cases. -- *Peter Chamberlain*
