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?
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
From the same server where the certificate will be installed, create CSR
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
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').
If you review the process of SSL negotiation at Wikipedia, you will know that at the beginning ClientHello and ServerHello messages are sent between the browser and the server.
Only if the cyphers provided in ClientHello have overlapping items on the server, ServerHello message will contain a cypher that both sides support. Otherwise, SSL connection will not be initiated as there is no common cypher.
To resolve the problem, you need to install cyphers (usually at OS level), instead of trying hard on the browser (usually the browser relies on the OS). I am familiar with Windows and IE, but I know little about Linux and Firefox, so I can only point out what's wrong but cannot deliver you a solution.
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 Firefox
ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome
It turned out to be an issue with using Java 8. When I switched to Java 7, the problem stopped.
Under advanced settings of firefox you should be able to set the encryption. By default SSL3.0 and TLS1.0 should be checked, so if firefox is trying to create ssl 3.0 connectons try unchecking the ssl 3.0s setting.
if that doesn't work, try searching the about:config page for "ssl2"
My Firefox has settings with ssl2 set to false by default...
The first thing I would check is the config for mod_nss. It is the odd one out, for it is yours and there is none in the world like it :-) Whereas if there was some huge bug in Firefox or mod_nss itself, I guess you'd have found out about it by now in your google quest. The fact that you've fiddled with the config (e.g. disabling SSL3, and various other random tweaks), is also suspicious.
I'd back track to a very vanilla mod_nss config and see if that works. Then change things systematically towards your current config until you can reproduce the problem. By the sound of it the source of the error is somewhere in the cipher spec config of mod_nss and the related protocol negotiation stuff. So maybe you inadvertently changed something there when trying to turn off SSLv3 (incidentally, why disable SSL3? Normally people disable V2?).
One other thing to check is that you're on the latest mod_nss and it's not a known bug in that. The fact that it manages to start the session and then fails later is interesting - it suggests that maybe it is trying to renegotiate the session and failing to negotiate ciphers at that point. So it might be the symmetric ciphers. Or it could simply be an implementation bug in your version of mod_nss that somehow garbles the protocol.
One other idea, and this is a wild guess, is the browser is trying to resume a session which was negotiated with SSLv3 before you disabled it, and something breaks when trying to resume that session when V3 is turned off, or maybe mod_nss just doesn't implement it right.
The java/tomcat stuff seems like a red herring as unless I've misunderstood your description, none of that is involved in the SSL handshake/protocol.
I had the same problem with a really old local router and was not able to open its WebGUI because of self-signed certificates. The solution was to install an old Firefox Portable version. I tested the following versions:
Firefox 33.1.1 (worked)
Firefox 45.0.2 (worked)
Firefox 56.0.2 (failed)
This is strange because it should be only a problem since version 59, but as long it works, it's ok for me.
If you get the no cipher overlap error on firefox, and you have left it at default settings, you are using what must be a very insecure site trying to use a very weak "export grade" cipher. Use of these ciphers is discouraged these days and I personally would stop using a site trying to use such a weak cipher.
I've had the same problem; to solve was enough to enable all the SSL schemas in "about:config". I was finding them by filtering with ssl. First I anabled all options for afret disabling the unnecessary ones.
"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
What worked for me is I:
Went to about:config.
Typed "security" in the search box.
Set all of the returned entries to their defaults.
Typed "ssl" in the search box.
Set all of the returned results to their defaults.
Enabled ssl2.
Disabled ssl3.
Restarted Firefox.
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
"Error code: ssl_error_no_cypher_overlap" error message after login, when Welcome screen expected--using Firefox browser
Solution
1: enter 'about:config' in Browser Address bar
2: find/select "security.ssl3.rsa_rc4_40_md5"
3: set boolean to TRUE
Related
We have developed an console application which will bring data from ESB (https://esb.mkcl.org/) which is on HTTPS. When I hit to this web site I get javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated exception. I changed URL to https://netbanking.hdfcbank.com/netbanking/ which is also on HTTPS and after giving hit I have NOT received any exception.
After some searching I come to know that I have to import public certificate in java's keystore i.e cacerts (C:\Program Files\Java\jre6\lib\security). So I exported certificate of https://esb.mkcl.org/ from browser and imported in java using keytool and then executed console application and it works!! no exception is occurred.
So the question is why I need to import certificate for that particulate URL (where as other HTTPS URLs are working without importing any certificate in java)?
The root certificate used by that server's certificate (COMODO RSA Certification Authority) was added to Java in Java 8 Update 51, so that means the java version you're using (java6 from your jre path) is too old to already include it.
To have that certificate trusted by default, update to a never java version.
And by the way, the ssl configuration for that server is pretty insecure.
A client-side SSL implementation relies on a set of known "trusted root certificates". These are certificates for SSL Certification Authorities that are known to be trusted / trustworthy.
The "problem" is that the set of trusted certs in the keystore that is distributed in your Java JDK / JRE is (typically) smaller than the set in a typical web browser.
There are reasons for this. For example:
A "server" Java installation probably needs to be more conservative on who to trust by default ... for security reasons.
You may be running an older (i.e. out of maintenance) version of Java. Obviously, Oracle will not be refreshing the keystore with new trusted certs.
Some JREs can make use of either the host OSes default keystore, or a browser keystore.
Access to the Mac OS X keystore was introduced in Java 7u4.
Browser plugins can use the browser keystore.
I have an Oracle service Bus domain running on weblogic 10.3.6 with 2 managed servers in cluster.
We have a proxy service deployed on this domain which goes to an external Business service for validating address. This Business Service is listening on SSL port and SSL cert has EntrustCACert>IntermidateCert1>IntermidateCert2>ServerCert
Issue: Getting below error during connectivity testing -
General runtime error: [Security:090548]The certificate chain received from ws2.site1.com - 197.109.80.xxx contained a V3 CA certificate which was missing the basic constraints.
Solutions i have tried:
1) added JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.security.SSL.enforceConstraints=off " in the startup script and it resolve the issue. But i was told this is not the prefered way and use trust keystore to implement.
2)to implement trust, I copied all the 4 certs in following reverse order EntrustCACert>IntermidateCert1>IntermidateCert2>ServerCert in one file named DSperian.pem and imported in Jrockit cacerts file( /apps/Oracle/jrockit-jdk1.6.0_31-R28.2.3-4.1.0/jre/lib/security/cacerts ) using below command but getting the same above error.
keytool -import -alias DSperian -trustcacerts -file DSperian.pem -keystore cacerts
Question:
Please let me know if im doing the right way to import cert to create trust. so my OSB domain will blindly trust the Business service ( web-service) and ignore
the "basic constraints" error. Do i need to utilize weblogic specific trust keystore file but this OSB weblogic is running on non-ssl port ?
are there any other options available ? Asking Business-service to update their cert to include "basic constraints" is not an option.
There is actually a problem with your certificate.
Security certificates have a set of constraints that allow them to perform certain functions (or restrict them to certain functions).
Have a look at each of the certificates and ensure that they have constraints assigned to them that are suitable for the task.
To get more details on the error enable SSL debugging in your web logic server add the following to your server startup script
-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
More information in Configure SSL in WebLogic server
Use the following command to validate your keystone
java utils.ValidateCertChain -jks my key mykeystore
Then, whoever provided the root certificate needs to fix up your issues.
I am making a call from one application sayApp1 to another application(say App2) authorized by verfied CA like Verisign or Thawte like
String urlStr="https://myApp2/welcome"
HttpsURLConnection conn1 = (HttpsURLConnection) url.openConnection();
conn1.getInputStream()
Do i need to import that certificate issued by App2 somewhere in
VM truststore of app1? This is the case when they are on different tomcat server(so different vm).
What about the same scenario if they are on same tomcat server(i mean same vm)?
i know in case of browser it is not required to import the certificate signed by CA's like verisign,thawte etc but what about when making the connection from java?
Edit:-
As you said This will be the same regardless of the server they are installed
It means ever webserver checks the cacerts file that shipped with Java 1.6.0_30 . so if client jvm has those certicates, we dont have to do anything.
This cacerts file check is done only when we are making the url connection from java code. In case of browser it will just check browser truststore.RIGHT?
To move my site to https i followed below step
C:\Program Files\Java\jdk1.6.0_23>keytool -genkey -alias tomcat -keyalg RSA which generated .keystore file
Finally i made changes in server.xml and it worked keystoreFile="c:/.keystore" keystorePass="changeit"
After going thru too many material on net i am bit confused about which approach i just followed(did i create my own CA or i just created self signed certificate which needs
to be present at client side) ?
It depends. The cacerts file that shipped with Java 1.6.0_30 has 76 entries. If the certificate used by the other application was verified by one of the those vendors using one of those certificates, no importing will be necessary. This will be the same regardless of the server they are installed on if the protocol used is HTTPS. Sometimes vendors have new certificates that will require updates to cacerts. This is typically fixed by JVM upgrades. If the public key of the certificate used to verify the other application is not in cacerts then it will need to be imported to establish trust.
Your question is really confusing (this is the least I can say).
You start saying that you need communication with an application that deploys a certificate signed by a trusted CA like Verisign and end up asking what kind of certificate does keytool generated that you used in your Tomcat!
Anyway:
Do i need to import that certificate issued by App2 somewhere in VM
truststore of app1? This is the case when they are on different tomcat
server(so different vm). What about the same scenario if they are on
same tomcat server(i mean same vm)?
This does not matter.If you don't define for your client app a specific truststore then java's default will be used.
If the app2 sends a certificate signed by a trusted issuer like Verisign then you don't have to do anything (as #laz also points out). Since Verisign's certificate should already be present in your java installation cacerts
After going thru too many material on net i am bit confused about
which approach i just followed(did i create my own CA or i just
created self signed certificate which needs to be present at client
side) ?
You created a self-signed certificate (and a private key of course). You will need to import this in your client's truststore and of course use that keystore as your server's keystore.
I'm connecting to a web service over HTTPS. I've done all that I think is required to make it work, but in the end I get a handshake failure.
I found out that as a new user I can't post more than 2 links due to "spam protection" - thanx a lot stackoverflow...anyway here's a link to a pastebin post with all the links spelled out...so when I write "link#1" here it's a reference to these links: http://pastebin.com/y4zGNRC7
I verified the same behavior using HttpClient (GET on the service URL) and actually calling the web service via a CXF proxy
I'm setting both the keystore and truststore - I tried both the "in code" way ( link#1 ) and setting the system properties - i.e. System.setProperty("javax.net.ssl.keyStore", "mykeystore.jks");
SSL debug is on ( javax.net.debug=all )
SSL debug blurts out the contents of both keystore and truststore (i.e. looks like java "knows about them") - link#2
seems like there's some client-server communication going on, but then it crashes for some reason link#3
I successfully connected to the server using the client and CA certificates both in a browser (Chrome) and using openssl s_client
wireshark shows less client-server talk from java ( link#4 ) then for example from Chrome ( link#5 )
Another strange thing is, that I seem to be getting the same behavior when I set the keystore and when I don't (the only difference is that when I do the keystore contents get printed in the console, but that's it).
I tried googling the problem and I saw numerous similar posts here on stackoverflow, but nothing helped.
I tried changing the protocol version ("TLSv1", "SSLv3", even the weird v2 Hello).
Any help would be appreciated - maybe there's some fundamental thing I might have overlooked...I'm getting desperate here...
Thanx
PS I'm running java 1.6 update 30 on Fedora Core 15 (64bit)
The problem was that even though the keystore and truststore was set, java decided not to send the client certificate to the server. The reason for this was the fact, that the server requested a certificate signed by the RootCA authority, but the client certificate is signed by a SubCA authority (which is issued by the RootCA).
Originally the keystore only contained the client cert and the truststore the SubCA cert.
I then tried to add the SubCA cert to the keystore too, but java just ignored it.
So this solves the hanshake failure mystery, but not my problem.
I created a separate question for that...sigh :-(
why doesn't java send the client certificate during SSL handshake?
I think the trust store not containing the CA is the most likely issue. You can use the Java keytool to import the certificate for the site into the cacerts file doing something like:
keytool -keystore pathtocacerts -import -trustcacerts -v -alias aliasName -file root.crt
The default cacerts keystore password is changeit. The cacerts file is usually under jre/lib/security directory.
You don't provide enough information, but I'm guessing your client truststore is not properly configured. The truststore contains the trusted certificates that are used to sign other certs, and must include the root certificate(s) for the server and client cert chains. The client keystore contains the client SSL certificate and private key.
I'm attempting an SSL connection from a ColdFusion 8 Enterprise client to a Redhat 5 Postgres server. Another party set up Postgres and sent me the certificates.
I imported root.crt into E:\JRun4\jre\lib\security\cacerts successfully and restarted the service.
The Postgres pg_hba.conf file has the client IP, and connects fine without SSL
Postgresql.conf has ssl=on
The server-side certs were created according to http://www.postgresql.org/docs/8.2/static/ssl-tcp.html and presumingly done correct.
With SSL enabled, I get org.postgresql.util.PSQLException: The connection attempt failed. which produces little helpful information from the searches I've done.
JDBC URL: jdbc:postgresql://x.x.x.x/main?ssl=true
Class: org.postgresql.Driver
What can be done to see/test if the error source is on my end or the server end?
Obvious questions to start with in troubleshooting something like this are:
Can you connect with SSL enabled using psql?
Is there anything of interest in the postgresql logs?
If that doesn't work, is there a way you can test the certificate against the root ca's signature?
If that fails, the only thing I can think of is tracing the client side and seeing exactly where in the SSL libraries it fails.
For certificate problems add &sslfactory=org.postgresql.ssl.NonValidatingFactory to your jdbc url. See https://jdbc.postgresql.org/documentation/91/ssl-client.html for more information.
I found the notes I took for solving this. Note that the drive and folder paths may be different for your setup.
Copy server.crt.der your destination server
Open a command window in your destination server and go to E:\Jrun4\jre\bin\
Type in the following command: keytool -importcert -alias postgres -keystore e:\jrun4\jre\lib\security\cacerts -file c:\location\of\server.crt -storepass changeit
It will prompt you whether you should trust this certificate; answer yes
To verify it successfully installed, type: keytool -list -alias postgres -keystore e:\jrun4\jre\lib\security\cacerts -storepass changeit. If successful you'll see a single listing return by that alias, otherwise it will say none found
After the certificate has been stored you may delete the actual certificate file from the server
Restart ColdFusion services on the client machine