My co-workers and I are having a problem using Firefox 3.0.6 to access a Java 1.6.0___11 web application we're developing. Everything works fine anywhere from 1-30 minutes into the session...but eventually, the connection fails and the following error appears:
Secure Connection Failed
An error occurred during a connection to 10.x.x.x.
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)
IE works fine. Firefox throws the error in both Windows and Fedora, so the problem doesn't appear to be tied to an OS. The Java EE application runs on a Tomcat 6.0.16 server. All pages are encrypted using TLS 1.0 through an Apache 2.2.8 HTTP server with mod_nss.
Our Apache server is configured to reject SSL 3.0 connections. One hypothesis we have is that Firefox might be trying to establish a SSL 3.0 connection...but why?
Based some Googling, we tried the following things, but without success:
using Firefox 2.x (some people reported instances where 2.x worked but 3.x didn't):
enabling SSL2
disabling SSL3
disabling OCSP (Tool > Options > Advanced > Encryption > Validation)
ensuring that the anti-virus/firewall of the client computer isn't blocking or scanning port 443 (https port)
Any ideas?
What worked for me is I:
Note about restarting Firefox: When I do start it very soon after closing it, it often has a file access problem, which requires me to delete places.sqlite and places.sqlite-journal in C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\n18091xv.default. This causes me to lose my history, plus bookmarks have to be restored from a backup each time this happens. I wait from five to ten minutes or more to avoid this hassle.
Running Firefox v3.5.1 on WinMe
I had the same issue while renewing the certificate for our server at www.tpsynergy.com . After importing the new server certificate and restarting the tomcat, the error we were getting was ERR_SSL_VERSION_OR_CIPHER_MISMATCH. After lot of research, I used this link https://www.sslshopper.com/certificate-key-matcher.html to compare the csr (certificate signing request to the actual certificate). They both did not match. So I created a new csr and obtained a new certificate and installed the same. It worked.
So the full steps for the process are
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tpsynergy.keystore (change the domain name as needed)
While creating this, it will ask for first name and last name. Do not give your name, but use the domain name. For example I gave it as www.tpsynergy.com
2.keytool -certreq -keyalg RSA -alias tomcat -file csr.csr -keystore tpsynergy.keystore
This will create a csr.csr file in the same folder. copy the contents of this to the godaddy site and create the new certificate.
The downloaded certificate zip file will have three files gd_bundle-g2-g1.crt gdig2.crt youractualcert.crt
You will need to download the root cert gdroot-g2.crt from godaddy repository.
Copy all these files to the same directory from where you created the CSR file and where the keystore file is located.
Now run the below commands one by one to import the certs into the keystore
keytool -import -trustcacerts -alias root -file gd_bundle-g2-g1.crt -keystore tpsynergy.keystore
keytool -import -trustcacerts -alias root2 -file gdroot-g2.crt -keystore tpsynergy.keystore
keytool -import -trustcacerts -alias intermediate -file gdig2.crt -keystore tpsynergy.keystore
keytool -import -trustcacerts -alias tomcat -file yourdomainfile.crt -keystore tpsynergy.keystore
Ensure that server.xml file in conf folder has this entry
Restart the tomcat
"Error code: ssl_error_no_cypher_overlap" error message after login, when Welcome screen expected--using Firefox browser
Solution
Enable support for 40-bit RSA encryption in the Firefox Browser: 1: enter 'about:config' in Browser Address bar 2: find/select "security.ssl3.rsa_rc4_40_md5" 3: set boolean to TRUE
Given what you've tried and the error messages, I'd say this was more to do with the exact cipher algorithm used rather than the TLS/SSL version. Are you using a non-Sun JRE by any chance, or a different vendor's security implementation? Try a different JRE/OS to test your server if you can. Failing that you might just be able to see what's going on with Wireshark (with a filter of 'tcp.port == 443').
I had similar issues browsing to secure sites (https://) when using Burp (or at least an issue that would bring you to this page when searching Google):
ssl_error_no_cypher_overlap
in FirefoxERR_SSL_VERSION_OR_CIPHER_MISMATCH
in ChromeIt turned out to be an issue with using Java 8. When I switched to Java 7, the problem stopped.