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.
Related
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 have two webapplication at prrduction say app1 and app2. Both are on different webservers. app1 is verified secure trust corporation and
app2 is verified by TrustWave Holdings,Inc . So both are verified CA's.App2 tries to make HttpsURLConnection to app1 and gets some SSLException. My question
is if both certificates are verfied ones, still do we need to make any certificate entry in jre\lib\security folder? As per my understanding
we do not need this if certificates are verified one. Any pointers will be great help.
EDIT:-
i am on jdk1.6. I am not sure whether these certificates i.e(secure trust corporation and TrustWave Holdings,Inc) are already there
in cacerts file under jre\lib\security. i could find on the web that these are included in mozzila and other browser but not
sure about jdk 1.6?
It takes some effort from a provider to have its root CA cert included in all browsers and iphones and tablets and whatnots. More often than not they don't bother getting their cert shipped with oracle or openjdk. That's the exact reason why we moved away from Godaddy to Comodo... If the server cert isn't bundled you can create a keystore with the issuer certs and yours and tell java to use it via commandline:
-Djavax.net.ssl.trustStore=yourkeystorefile.jks -Djavax.net.ssl.keyStore=yourkeystorefile.jks
technically you would put the servers cert+key in the keystore and cert chain from the issuer to the truststore, but it's fine for java if the two are mixed in one keystore file
You will likely need to add these to /security/cacerts. By default Java does trust some certificate authorities. I'm not sure TrustWave is one of them.
View the keystore using the following command and see if TrustWave is in there.
keytool -list -keystore /usr/java/jdk1.6.0_14/jre/lib/security/cacerts
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 trying to set up a test environment for our application that uses X.509 client authentication over HTTPS in Tomcat 6.0. The servlet code is expecting to get a certificate chain as an array of X509Certificate objects using the javax.servlet.request.X509Certificate of the servlet request. However, this array only contains a single item (the client certificate), where I'm expecting it to have two (the client certificate and the root CA certificate that signed it).
Here's what I've done so far:
Generate a self-signed CA certificate using openssl.
Import the CA certificate as a trusted root certificate into a newly create Java keystore.
Configure the Tomcat HTTPS connector to require client authentication using the keystore created in step 2 as the truststore:
clientAuth="true"
truststoreFile="<path_to_truststore>"
Generate a new client certificate using openssl and sign it with the CA certificate.
Start Tomcat.
Install the client certificate in Chrome and navigate to my server's homepage. Stepping through the code in debug, I can see that the array returned as the javax.servlet.request.X509Certificate attribute only has the client certificate.
I know that Tomcat is picking up the root CA certificate from the truststore because when I delete it from the truststore, I get an SSL connection error. It's just not making it into the servlet request like the documentation says it should. Am I missing any additional configuration here? Perhaps Tomcat (or Java or JSSE) is expecting some additional X509 V3 extensions or something?
Any help is appreciated!
EDIT
Looks like my setup is legit, and this falls into the category of unusual but expected behavior due to a simplified test environment. In an enterprise scenario it's unlikely that the root certificate authority is going to be directly signing client certificates for individual users. Clearly when this code was written and tested, there was at least one intermediate CA involved in the trust chain.
What your are seeing is what is expected: Chrome is not sending the CA.
During the TSL Handshake when authenticating the client, the server will send a list of acceptable CAs as part of its CertificateRequest Message (RFC), the browser will then present a Certificate signed by one of these CAs.
ADD
btw, a great way of debugging an SSL connection client side is to use the fantastic openssl tools
openssl s_client -connect ssl.server.com:443
or for SSLV3 only servers
openssl s_client -connect ssl.server.com:443 -ssl3
This will print (among other things) the list of acceptable CAs.
To debug the server side add this to the JVM command line -Djavax.net.debug=ssl
The identity keystore should contain the cert signed by the CA ; not the self-signed cert. The CA root should be in the truststore.
Also, what is the purpose of step 4 ?
While I've been familiar with HTTPS and the concept of SSL, I have recently begun some development and found I am a little confused.
The requirement was that I write a small Java application that runs on a machine attached to a scanner. When a document is scanned this is picked up and the file (usually PDF) sent over the internet to our application server that will then process it. I've written the application using Apache Commons libraries and HTTPClient.
The second requirement was to connect over SSL, requiring a certificate. Following guidance on the HTTPclient page I am using AuthSSLProtocolSocketFactory from the contributions page.
The constructor can take a keystore, keystore password, truststore and truststore password. As an initial test our DBA enabled SSL on one of our development webservers and provided me with a .p12 file which when I imported into IE allows me to connect successfully.
I am a bit confused between keystores and truststores and what steps I need to take using the keytool. I tried importing the p12 into a keystore file but get the error:
keytool error: java.lang.Exception: Input not an X.509 certificate
I followed a suggestion of importing the p12 into Internet Explorer and exporting as a .cer which I can then successfully import into a keystore. When I supply this as a keystore argument of the AuthSSLProtocolSocketFactory I get a meaningless errror, but if I try it as a truststore it seems like it reads it fine but ultimately I get
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
I am unsure if I have missed some steps, I am misunderstanding SSL and mutual authentication altogether or this is mis-configuration on the server side.
Can anyone provide suggestions or point me towards resources that might help me figure this out please?
The keystore holds your private keys and associated certificates. The truststore hold the certificates that you trust and that can therefore be used for certificate path building and verification.
Here are some links that may be useful:
java.lang.Exception: Input not an X.509 certificate
Import private key and certificate into Java Key Store
Configuring Keystores and Truststores
make sure your certificate file does not have anything before and after these.
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----