JAS SSL (ssl_error_no_cypher_overlap and SSLHandshakeException: no cipher suites in common)
Hi,
I am supporting a DOORS Next Generation Evaluation and my customer needs to have company certificates (for evaluation within Company network we can send the CSR to Company Certification Authority and request a return certificate) in Jazz Authentification Server. I have problems with SSL certificate management in my Jazz Authentification Server and CLM installation. I am always running in ssl_error_no_cypher_overlap or handshake errors (com.ibm.ws.channel.ssl.internal.SSLHandshakeErrorTracker E CWWKO0801E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLHandshakeException: no cipher suites in common at com.ibm.jsse2.ab.B(ab.java:285) at com.ibm.jsse2.nc.b(nc.java:554) at com.ibm.jsse2.nc.c(nc.java:261) at com.ibm.jsse2.nc.wrap(nc.java:25) at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:39)) Environment: SUSE Linux 11 Enterprise, JAS/JTS 6.0.2 or 6.0.3M6 with Websphere Liberty Profile, IE 11 and for testing Firefox Steps: I used the documented steps of the jazz article https://jazz.net/library/article/1539 1. Creating Keystore with keytool (JAS installation) as a mykeystore.jks with alias sslkey 2. Creating Cert-Request 3. Sending Cert-Request to Company CA 4. Downloading the needed Root Certificates for Intranet 5. Importing Company Root Certificates in Trusted List of the Application (/java/jre/lib/security/cacerts) 6. Company Certificat Authority sends a trusted certificate back. I save the content from “BEGIN” to „END“ in a Cer-file. I used several test scenarios for adding the certifcate to my original keystore: 7a: Using the same alias like in step one (e.g. sslkey) ./server/jre/bin/keytool -import -alias sslkey -keystore mykeystore.jks -trustcacerts -file ./server/jre/bin/dng_cert.cer 7b: Using a different name for the alias 7c: Not using the -trustcacerts parameter in my import 8. I imported in some tests the root certificates into my keystore too (like in the Tomcat documentation) 9. Copy Keystore to /server/liberty/servers/clm/resources/security 10. Updating the JAS appConfig.xml and re-start Server Unclear: Has the alias for the import of the trusted certificate be the same name like in my first created Keystore? If yes, the keytool -list statement give my "trustedCertEntry" only. If no, I have my in step 1 created keystore as a "keyEntry". I am missing a private key in my keystore. Is this the reason for my problems? Testcases: Referencing in appConfig the serverKeyAlias to: - updated alias entry with trusted Certificate from Company CA -> Result: Application is broken SSLHandshakeException: no cipher suites in common - the original alias entry (the imported trusted Certificate has a different alias) -> Result: Application is working, but with Certificate Error in Browser (This connection is untrusted), because the serverKeyAlias is referencing to my self-created certificate and not to the "trusted" entry from CA. Thanks for any help. Hubert |
One answer
|
Many thanks for your help.
I solved the problem! My problem was the import order of the certificates. First I have to import the Customer Root certificates into my keystore and in the very last step the CER File from Certificate Authority. And it is important that I don't use -trustcacerts in the import statement for the CER File (the keystore needs this entry as a privateKeyEntry and not trustedCertEntry). And it was important for me to use the Oracle JRE from my local desktop (jre 1.8.0- 112) and not the JAS/JTS JRE. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
The error may have nothing to do with the certificate, as it complains about the cipher suites (that is something like TLS_RSA_WITH_AES_256_CBC_SHA). You didn't make it clear exactly when or where you got the error. In other words, which client (application) throws this error when it tries to connect to which server? If you know which client/application throws the error, add "-Djavax.net.debug=ssl:handshake:verbose" to the startup script and you should see some very detailed information about the SSL handshake in the log file.
Thanks Donald for your answer. I tested in JAS (Websphere Liberty Profile) and in Tomcat 8.5.x (Tomcat alone without connected to other applications). After starting JAS or Tomcat I've got the errors in the log and the website cannot be display.
In IE: This page can't be displayed Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in the Advanced settings
I looked into the IE settings and it is activated (I used a standard IE within my company and the settings are managed from Global IT).
Hubert, I think Donald is on the right track here. Your problem is that the set of cypher suites allowed by your browser and those allowed by your server don't have any common entries.
You need to look and see how the set of allowable suites is defined in your server (in tomcat I think it's usually in server.xml but I'm not 100% certain).
There's a lot of movement at the moment around these with various browser vendors killing off older suites (like all the SSL ones and even TLS 1.0 and 1.1 I think) so their browsers won't talk to servers with these cyphers by default.
-Dominic
Hubert, you need to make it clear when and where the SSL handshake error occurs, otherwise you should contact Support so that all your configuration files and log files can be sent for examination.
You keep saying the errors in the "log" but do not say which "log". The error message in the OP is related to WebSphere (Liberty), but do you get the same error in Tomcat?
If you believe that the issue is related to IE, check out the below documents and see if you can get your head around it.
https://support.microsoft.com/en-au/kb/3161639
https://support.microsoft.com/en-au/kb/3151631
Also, when you configure SSL in the JAS profile, you should come across the Liberty parameters such as "enabledCiphers".
http://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/rwlp_ssl.html?cp=SSEQTP_8.5.5
If this is all Greek to you, please contact Support.