Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 8/5/20 16:39, James H. H. Lampert wrote: > First, I did a quick SSLLabs scan on the server. That told me that > "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it > told me that all simulated Chrome handshakes failed, but most other > simulated handshakes were fine. If you want something a little more quick-and-dirty than SSLLabs's test (which is excellent!), you could use this tool: https://github.com/ChristopherSchultz/ssltest You will need to compile it; or I can sent you an executable JAR file if you trust me. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sJY8ACgkQHPApP6U8 pFipSxAAlF0HMCYCHIbnwBF84RmlFPdqAisKsfy8y9ssNQ5pdBzadVasq2NSfVx4 OMNe+7+BWvQApKzL6VN/8joyS2JllIUDhla9Pa2LfgycvxNsy3j3nMA5PpPKipAs 8Ki1b3eNmRr+G7X4yRrccHpragvJeKmLBJz615gNxsjpOvYIwgLNwKcJH1etdpZW RtjexJictl8KAGf/S5Gzg6ctgHoobTW1+tGohr3/U59WmGdy1rNQQbBuX9OFz3E4 K5PHmJAa7T7u+LLtw/G0SKZ6Uyk/WRrCJVLD3nSa/AmL0D/fJa+l52BMsdhsCJKG UYE5HSq8ycU2q4ly49EW1SucT0fuBkztUBHNeCKbWH3qb/yan/7QS0ZPsBQd0uI1 mFAr+ErGkuo00sGhU2UrhSQHzQ+xhmX48HebXRWHfzC131cP3t7pYedrF/nNorbh kPmSODePIWlIMMhbbpIvfsTB33YY/HkZGPhsUONEUltjnB71ljt/0886fFnDfFYp XNXhTvFVzTmh4qYmXG2YkwsVTCujyBbX68niumuphvkIHhSsF6mBvwLhtDVBPBkG zvxTamu4e/nUAhAwQeFH3dyP8iCr3MHBo+MRSHiyamU6uup0j2Uley+AoKd0ih6T +3x3iyD4vCnO9fFRAvbfOCV5vrSviUJjcss4b6PU9BKwAWGwaiQ= =HHU/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
Good job with those tests and good luck with the real site! Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: James H. H. Lampert Sent: Wednesday, August 5, 2020 3:39 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! Jon Mcalexander wrote: > Most likely then you need to find a cypher list that is valid for TLSv1.2. > Such as below: > > ACCEPTABLE > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_CBC_SHA256 > TLS_RSA_WITH_AES_128_CBC_SHA256 > > IDEAL > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > TLS_RSA_WITH_AES_128_GCM_SHA256 I came up with a couple of things to try, while I was at lunch. First, I did a quick SSLLabs scan on the server. That told me that "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it told me that all simulated Chrome handshakes failed, but most other simulated handshakes were fine. Then (directly violating the "change only one variable at a time" principle) I set it back to "protocols," *and* cut out the cipher list entirely. That worked just fine. The weird part is that so far as I can tell, the cipher list looks *exactly* like the cipher list in the original Java Keystore version of the connector I compared the cipher lists given in the SSLLabs reports for three cases: the new connector with the old cipher list, the new connector with no cipher list at all, and (using the live version of the server) the old connector with the old cipher list, and the results were remarkable: test, no cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp521r1 (eq. 15360 bits RSA) FS128 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) 128 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) 128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp521r1 (eq. 15360 bits RSA) FS256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) 256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032) 256 test, with old cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
Jon Mcalexander wrote: Most likely then you need to find a cypher list that is valid for TLSv1.2. Such as below: ACCEPTABLE TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 IDEAL TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 I came up with a couple of things to try, while I was at lunch. First, I did a quick SSLLabs scan on the server. That told me that "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it told me that all simulated Chrome handshakes failed, but most other simulated handshakes were fine. Then (directly violating the "change only one variable at a time" principle) I set it back to "protocols," *and* cut out the cipher list entirely. That worked just fine. The weird part is that so far as I can tell, the cipher list looks *exactly* like the cipher list in the original Java Keystore version of the connector I compared the cipher lists given in the SSLLabs reports for three cases: the new connector with the old cipher list, the new connector with no cipher list at all, and (using the live version of the server) the old connector with the old cipher list, and the results were remarkable: test, no cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp521r1 (eq. 15360 bits RSA) FS 128 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) 128 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) 128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp521r1 (eq. 15360 bits RSA) FS 256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) 256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032) 256 test, with old cipher list TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) WEAK 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) WEAK128 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) WEAK 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) WEAK256 original connector, with old cipher list TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256 The test with no cipher list produced (I think) five matches with your "acceptable" list, two of which were also on your "ideal" list. The test with the old cipher list on the new connector produced only 12 of the 18 on the "no cipher list" test, none of which were on either of your lists. And the original connector produced what appears to be a completely different list in the report, with nothing in common with the other two, or with your lists, and yet it is TLS 1.2-only, and it seems to get along just fine with
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
-Original Message- From: James H. H. Lampert Sent: Wednesday, August 5, 2020 1:06 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! On 8/5/20 10:43 AM, calder wrote: > certificateVerificationh="none" > > there's one issue (misspelling), though may not be a contributing > factor. > Corrected; no effect. > Jon McAlexander wrote: > I believe that > > protocols="TLSv1.2"> > > should be > > sslEnabledProtocol="TLSv1.2" > My understanding of the instructions is that "protocols" is correct for an > SSLHostConfig, whereas "sslEnabledProtocols" is correct > for a Connector > without an SSLHostConfig. At any rate, I tried "protocols," > "sslEnabledProtocol," and "sslEnabledProtocols"; no effect. Firefox still > likes it just fine (and so does Safari), but Chrome chokes on > it (and if > there's a diagnostic to tell me the gory details of WHY it's choking on it, I > don't know where to find it). And both Chrome > > and Firefox like the new LE > cert just fine in httpd. > If it will help, the real domain is > https://test.wintouch.net > -- > JHHL Most likely then you need to find a cypher list that is valid for TLSv1.2. Such as below: ACCEPTABLE TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 IDEAL TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
On 8/5/20 10:43 AM, calder wrote: certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. Corrected; no effect. Jon McAlexander wrote: I believe that protocols="TLSv1.2"> should be sslEnabledProtocol="TLSv1.2" My understanding of the instructions is that "protocols" is correct for an SSLHostConfig, whereas "sslEnabledProtocols" is correct for a Connector without an SSLHostConfig. At any rate, I tried "protocols," "sslEnabledProtocol," and "sslEnabledProtocols"; no effect. Firefox still likes it just fine (and so does Safari), but Chrome chokes on it (and if there's a diagnostic to tell me the gory details of WHY it's choking on it, I don't know where to find it). And both Chrome and Firefox like the new LE cert just fine in httpd. If it will help, the real domain is https://test.wintouch.net -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connector works fine with Firefox, but not on speaking terms with Chrome!
I believe that protocols="TLSv1.2"> should be sslEnabledProtocol="TLSv1.2" Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: calder Sent: Wednesday, August 5, 2020 12:43 PM To: Tomcat Users List Subject: Re: Connector works fine with Firefox, but not on speaking terms with Chrome! On Wed, Aug 5, 2020, 12:22 James H. H. Lampert wrote: > I've now managed to get an experimental copy of our development AWS > EC2 instance working with a cert from Let's Encrypt, and I've got > Tomcat to launch with a modified connector that uses the LE certs > rather than a Java Keystore file. > > It looks great from Firefox (except for the still-unanswered riddle of > the unwanted Tomcat update), but from Chrome, I get (domain name > "changed to protect the innocent"): > > > This site can’t provide a secure connection > > > > test.foo.net uses an unsupported protocol. > > > > ERR_SSL_VERSION_OR_CIPHER_MISMATCH > > > > Unsupported protocol > > > > The client and server don't support a common SSL protocol version or > cipher suite. > > The modified connector looks like this: > > protocol="org.apache.coyote.http11.Http11NioProtocol" > compression="on" compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > > > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" > maxThreads="1000" socket.appReadBufSize="1024" > socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" > scheme="https" secure="true"> > > ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AE > S_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_S > HA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_S > HA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA2 > 56,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_ > SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" > certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. sslProtocol="TLS" > protocols="TLSv1.2"> >certificateFile="/etc/tomcat8/test.foo.net.crt" > certificateKeyFile="/etc/tomcat8/test.foo.net.key" > > certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> > > > > > Can anybody shed any light on what I did wrong? > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector works fine with Firefox, but not on speaking terms with Chrome!
On Wed, Aug 5, 2020, 12:22 James H. H. Lampert wrote: > I've now managed to get an experimental copy of our development AWS EC2 > instance working with a cert from Let's Encrypt, and I've got Tomcat to > launch with a modified connector that uses the LE certs rather than a > Java Keystore file. > > It looks great from Firefox (except for the still-unanswered riddle of > the unwanted Tomcat update), but from Chrome, I get (domain name > "changed to protect the innocent"): > > > This site can’t provide a secure connection > > > > test.foo.net uses an unsupported protocol. > > > > ERR_SSL_VERSION_OR_CIPHER_MISMATCH > > > > Unsupported protocol > > > > The client and server don't support a common SSL protocol version or > cipher suite. > > The modified connector looks like this: > > protocol="org.apache.coyote.http11.Http11NioProtocol" > compression="on" compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > > > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" > maxThreads="1000" socket.appReadBufSize="1024" > socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" > scheme="https" secure="true"> > > ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, > > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, > > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" > certificateVerificationh="none" there's one issue (misspelling), though may not be a contributing factor. sslProtocol="TLS" > protocols="TLSv1.2"> >certificateFile="/etc/tomcat8/test.foo.net.crt" > certificateKeyFile="/etc/tomcat8/test.foo.net.key" > > certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> > > > > > Can anybody shed any light on what I did wrong? >
Connector works fine with Firefox, but not on speaking terms with Chrome!
I've now managed to get an experimental copy of our development AWS EC2 instance working with a cert from Let's Encrypt, and I've got Tomcat to launch with a modified connector that uses the LE certs rather than a Java Keystore file. It looks great from Firefox (except for the still-unanswered riddle of the unwanted Tomcat update), but from Chrome, I get (domain name "changed to protect the innocent"): This site can’t provide a secure connection test.foo.net uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite. The modified connector looks like this: protocol="org.apache.coyote.http11.Http11NioProtocol" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" scheme="https" secure="true"> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" certificateVerificationh="none" sslProtocol="TLS" protocols="TLSv1.2"> certificateFile="/etc/tomcat8/test.foo.net.crt" certificateKeyFile="/etc/tomcat8/test.foo.net.key" certificateChainFile="/etc/tomcat8/test.foo.net.issuer.crt"/> Can anybody shed any light on what I did wrong? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
