I suspect we have the same symptom but not the same cause? Again, I'm using jetty out-of-the box and I see on the Jetty console:
2017-02-27 15:27:50.208:INFO:oejus.SslContextFactory:main: x509=X509à3730184(jetty,h=°§,w=°§) for SslContextFactoryàb91daf6c(file:///users1/degenaro/install/sandbox/etc/keystore,file:///users1/degenaro/install/sandbox/etc/keystore) And the keystore file indeed exists. Could it be that my keystore/truststore (and/or certificate) is foobar, ultimately causing the ERR_SSL_VERSION_OR_CIPHER_MISMATCH? On Mon, Feb 27, 2017 at 3:56 PM, Bruggheman, Xavier (Consultant) < [email protected]> wrote: > Hi, > > > We've hit the same issue using the maven jetty plugin after upgrading from > Jetty v9.2.10 to v9.4.2 due to a new "jetty-ssl-context.xml" file which > the ssl module now loads when using start.ini, and which was missing from > the list of JettyXml files we configure the jetty plugin with. > > > This meant that the jetty-https.xml wasn't able to get an > sslContextFactory, and failed on each HTTPS request, I suppose because it > had no identity to present to the client. > > > We found that out with the jetty dump tool (https://www.eclipse.org/ > jetty/documentation/current/jetty-dump-tool.html), which showed that our > SslContextFactory had both keystore and truststore to null where they > previously appeared with their full path (shortened to keystore_path and > truststore_path in the example below) : > > > ....snip.... > > += ServerConnector@1c5a1142{SSL-http/1.1}{0.0.0.0:8443} - STARTED > > | +~ org.eclipse.jetty.maven.plugin.JettyServer@69fa24d7 - STARTED > | +~ qtp1491807845{STARTED,10<=10<=200,i=4,q=0} - STARTED > | +~ org.eclipse.jetty.util.thread.ScheduledExecutorScheduler@8a246a7 > - STARTED > | +- org.eclipse.jetty.io.ArrayByteBufferPool@7f89606d > | += SslConnectionFactory@1e3622e1{SSL-http/1.1} - STARTED > | | += SslContextFactory@7f2494bb(keystore_path,truststore_path) - > STARTED > | += HttpConnectionFactory@75a8e29f{HTTP/1.1} - STARTED > | | +- HttpConfiguration@41967e4f{32768/8192,8192/8192,https://: > 8443,[SecureRequestCustomizer@6e987db6]} > > ....snip.... > > We later hit another issue related to the lack of default value for the > new jetty.sslContext.trustStoreType property in the jetty-ssl-context.xml > file, which lead to NPEs when the truststore was being loaded. > > > Now that we've added the jetty-ssl-context.xml file and set the > jetty.sslContext.trustStoreType to JKS it's working just fine, so I'd > suggest looking into how your keystore and truststore are configured when > you add the HTTPS connector to your server. > > > Xavier BRUGGHEMAN > ------------------------------ > *De :* [email protected] <[email protected]> > de la part de Simone Bordet <[email protected]> > *Envoyé :* dimanche 26 février 2017 15:06:34 > *À :* JETTY user mailing list > *Objet :* Re: [jetty-users] ERR_SSL_VERSION_OR_CIPHER_MISMATCH > > Hi, > > On Sat, Feb 25, 2017 at 1:56 PM, Lou DeGenaro <[email protected]> > wrote: > > It probably should help, but didn't. > > > > I've now switched to IBM JDK, for reasons of availability of security > > policies. > > > > bash-4.1$ /users/degenaro/install/ibm-java-x86_64-80/bin/java -version > > java version "1.8.0" > > Java(TM) SE Runtime Environment (build pxa6480sr4fp1-20170215_01(SR4 > FP1)) > > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References > > 20170209_336038 (JIT enabled, AOT enabled) > > J9VM - R28_20170209_0201_B336038 > > JIT - tr.r14.java.green_20170125_131456 > > GC - R28_20170209_0201_B336038_CMPRSS > > J9CL - 20170209_336038) > > JCL - 20170215_01 based on Oracle jdk8u121-b13 > > > > In /users/degenaro/install/ibm-java-x86_64-80/jre/lib/security I > installed > > local_policy.jar and US_export_policy.jar comprising: > > > > bash-4.1$ cat default_local.policy > > // Country-specific policy file for countries with no limits on crypto > > strength. > > grant é > > // There is no restriction to any algorithms. > > permission javax.crypto.CryptoAllPermission; > > è; > > > > bash-4.1$ cat default_US_export.policy > > // Manufacturing policy file. > > grant é > > // There is no restriction to any algorithms. > > permission javax.crypto.CryptoAllPermission; > > è; > > > > I launch the Jetty sever: > > > > /users/degenaro/install/ibm-java-x86_64-80/bin/java -jar > > /users/degenaro/jetty/start.jar -Djavax.net.debug=all > > > > I visit via https + 8443 using Chromium, and on the Jetty console I see: > > > > 2017-02-25 07:34:18.345:INFO:oejsh.ContextHandler:main: Started > > o.e.j.w.WebAppContextà-494073ddé/test,file:///users1/ > degenaro/install/sandbox/webapps/test/,AVAILABLEèé/testè > > 2017-02-25 07:34:18.375:INFO:oejs.AbstractConnector:main: Started > > ServerConnectorà4a3b91daéHTTP/1.1,°http/1.1§èé0.0.0.0:8080è > > 2017-02-25 07:34:18.407:INFO:oejus.SslContextFactory:main: > > x509=X509àdfac8979(jetty,h=°§,w=°§) for > > SslContextFactoryàfc940f90(file:///users1/degenaro/ > install/sandbox/etc/keystore,file:///users1/degenaro/ > install/sandbox/etc/keystore) > > adding as trusted cert: > > <cert info> > > Algorithm: RSA; Serial number: 0x7866 > > Valid from Thu Feb 18 00:00:00 EST 2016 until Sat Feb 16 23:59:59 EST > 2019 > > > > Installed Providers = > > IBMJSSE2 > > IBMJCE > > IBMJGSSProvider > > IBMCertPath > > IBMSASL > > IBMXMLCRYPTO > > IBMXMLEnc > > IBMSPNEGO > > SUN > > SSLContextImpl: Using X509ExtendedKeyManager com.ibm.jsse2.aw > > SSLContextImpl: Using X509TrustManager com.ibm.jsse2.aA > > JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version > > 1.8 > > trigger seeding of SecureRandom > > done seeding SecureRandom > > IBMJSSE2 will enable CBC protection > > JsseJCE: Using SecureRandom IBMSecureRandom from provider IBMJCE version > > 1.8 > > JsseJCE: Using KeyAgreement ECDH from provider IBMJCE version 1.8 > > JsseJCE: Using signature SHA1withECDSA from provider TBD via init > > JsseJCE: Using signature NONEwithECDSA from provider TBD via init > > JsseJCE: Using KeyFactory EC from provider IBMJCE version 1.8 > > JsseJCE: Using KeyPairGenerator EC from provider TBD via init > > JsseJce: EC is available > > JsseJCE: Using cipher AES/GCM/NoPadding from provider TBD via init > > CipherBox: Using cipher AES/GCM/NoPadding from provider from init IBMJCE > > version 1.8 > > JsseJCE: Using cipher AES/CBC/NoPadding from provider TBD via init > > CipherBox: Using cipher AES/CBC/NoPadding from provider from init IBMJCE > > version 1.8 > > jdk.tls.client.protocols is defined as null > > SSLv3 protocol was requested but was not enabled > > SSLv3 protocol was requested but was not enabled > > SUPPORTED: °TLSv1, TLSv1.1, TLSv1.2§ > > SERVER_DEFAULT: °TLSv1, TLSv1.1, TLSv1.2§ > > CLIENT_DEFAULT: °TLSv1, TLSv1.1, TLSv1.2§ > > IBMJSSE2 will enable CBC protection > > Using SSLEngineImpl. > > 2017-02-25 07:34:19.273:INFO:oejs.AbstractConnector:main: Started > > ServerConnectorà4dcc4f21éSSL,°ssl, http/1.1§èé0.0.0.0:8443è > > 2017-02-25 07:34:19.276:INFO:oejs.Server:main: Started à3044ms > > Finalizer thread, called close() > > Finalizer thread, called closeInternal(true) > > Using SSLEngineImpl. > > Finalizer thread, called closeSocket(true) > > Using SSLEngineImpl. > > IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate > set > > to none or default > > IBMJSSE2 will not require renegotiation indicator during initial > handshake > > per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default > taken > > IBMJSSE2 will not perform identity checking against the peer cert check > > during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check > set to > > OFF or default > > IBMJSSE2 will allow client initiated renegotiation per > > jdk.tls.rejectClientInitiatedRenegotiation set to FALSE or default > > > > Is initial handshake: true > > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_ > CBC_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_256_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_256_ > CBC_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384 > > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_256_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_256_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_ > CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_ > CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_CBC_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_ > GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_128_ > GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_256_ > GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_256_GCM_SHA384 > > Ignoring unsupported cipher suite: SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_RSA_WITH_AES_128_GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDH_ECDSA_WITH_AES_128_ > GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 > > Ignoring unsupported cipher suite: SSL_DHE_DSS_WITH_AES_128_GCM_SHA256 > > °Raw read§: length = 5 > > 0000: 16 03 01 00 bc ..... > > > > °Raw read§: length = 188 > > ... > > So. > > A) you have weird logs of > > "> JsseJCE: Using signature SHA1withECDSA from provider TBD via init" > > The provider "TBD" looks weird, "To Be Defined" ? > > B) the logs in the form of > > > Ignoring unsupported cipher suite: SSL_ECDHE_ECDSA_WITH_AES_256_ > CBC_SHA384 > > mean that you don't have those ciphers available. > In fact, that is a non-standard name because it starts with "SSL_", > while it should start with "TLS_" > (https://www.ietf.org/rfc/rfc5289.txt). > > You should ask IBM about those 2. It's a JVM configuration problem > more than a Jetty one. > > -- > Simone Bordet > ---- > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > > IPC ranks #33 in IDC's Top 100 FinTech > > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it by > any means. Please delete it and any attachments and notify the sender that > you have received it in error. Unintended recipients are prohibited from > taking action on the basis of information in this e-mail. E-mail messages > may contain computer viruses or other defects, may not be accurately > replicated on other systems, or may be intercepted, deleted or interfered > with without the knowledge of the sender or the intended recipient. If you > are not comfortable with the risks associated with e-mail messages, you may > decide not to use e-mail to communicate with IPC. IPC reserves the right, > to the extent and under circumstances permitted by applicable law, to > retain, monitor and intercept e-mail messages to and from its systems. > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
