I apologise for the confusion, but I was trying to figure out where the problem
lies, so I was jotting down any differences I see between whats working and
whats not.. I think I found out why it stops working when IIS is put back in
the mixture, Its not IIS its the JAVA code itself. We have multiple connection
code doing HttpsURLConnection, but the javax.net.ssl properties that being set
are different for the two piece of code. And one setting is affecting the other.
1) When doing the httpsurlconnection for another vendor( say vendor A), we
have some code which is as follows:
cacerts_path is not cacerts file, we imported the public key for VENDOR A in
a separate truststore.
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.ssl.trustStore", cacerts_path);
System.setProperty("javax.net.ssl.keyStorePassword", cacerts_pwd);
com.sun.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(new
HostnameVerifier() {
public boolean verify(String urlHost, String certHost) {
return true;
}
});
// setup the JSSE handler for the connection
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
But I read that these lines of code is no longer needed as of JDK 1.4 right,
if we place the public key in the %JAVA_HOME%/jre/lib/security/cacerts file. Is
this true? This piece of code is conflicting with the settings for the
following code.
2) The following piece of code executes for VENDOR B whose requirement is
client authentication. Hence we created this keystore with the private key in
it.
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.ssl.keyStorePassword", _storePwd);
System.setProperty("javax.net.ssl.keyStore", _keystorePath);
URL urlToConnect = new URL(_url);
HttpURLConnection conn = (HttpURLConnection)
urlToConnect.openConnection();
conn.setRequestMethod("POST");
conn.setDoOutput(true);
OutputStreamWriter wr;
wr = new OutputStreamWriter(conn.getOutputStream());
wr.write(_parameter);
wr.flush();
wr.close();
Once you run the code for VENDOR A, VENDOR B code stops working, i.e, VENDOR
B does not get the private key in the keystore. VENDOR A works all the time.
Refer to (1) code snippet
>>But I read that this is no longer needed as of JDK 1.4 right, if we place
the public key in the %JAVA_HOME%/jre/lib/security/cacerts file. Is this true?
This piece of code is conflicting with the settings for the following code.
>>
After reading this, I imported the public key for VENDOR A into the
%JAVA_HOME%/jre/lib/security/cacerts but I am getting the following
exception when I execute VENDOR A code.
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderExce
ption: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1
476)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Clien
tHandshaker.java:843)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHa
ndshaker.java:106)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:4
95)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.jav
a:433)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.j
ava:815)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SS
LSocketImpl.java:1025)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketIm
pl.java:1038)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:
405)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
(AbstractDelegateHttpsURLConnection.java:170)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLCo
nnection.java:828)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Htt
psURLConnectionImpl.java:230)
at com.hh.ecs.ComObject.UploadFiles(Unknown Source)
at com.hh.ecs.ComObject.main(Unknown Source)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find vali
d certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.jav
a:145)
at sun.security.validator.Validator.validate(Validator.java:203)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(
X509TrustManagerImpl.java:172)
at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(
SSLContextImpl.java:320)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Clien
tHandshaker.java:836)
... 12 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCert
PathBuilder.java:236)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216)
... 17 more
Thanks for the reading,
Rumpa Giri
Tim Lucia <[EMAIL PROTECTED]> wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
To answer your most-recent question below, accessing the outside URL
should not involve IIS on your local box (the http client). Its not clear to
me from your original post which is the client and which is the server. Sounds
like you have a client and two servers where one is your local copy of the
vendors production server? What Ive read (three times now) is that
When we put the IIS back in mixture, it does not work anymore
This statement was the basis for my original reply.
Tim
---------------------------------
From: Rumpa Giri [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 06, 2006 1:01 AM
To: Tim Lucia; 'Tomcat Users List'
Subject: RE: Tomcat /JSSE help needed
On our QA machine, we have the IIS and tomcat both on the same box, IIS has
the redirector also. Now on this box we did not install the certificate but
its still working.
When we do the httpsurlconnection via the java code to the outside URL, is
IIS involved at all?
Thanks,
Rumpa
Tim Lucia <[EMAIL PROTECTED]> wrote:
Wouldn't you need IIS to have the certificate, rather then Tomcat? Just a
guess, as I read this. It *appears* that IIS would be making the SSL
connection (https) outbound while speaking AJP over 8009 to Tomcat.
Tim
-----Original Message-----
From: Rumpa Giri [mailto:[EMAIL PROTECTED]
Sent: Monday, June 05, 2006 10:47 PM
To: Tomcat UserGroup
Subject: Tomcat /JSSE help needed
Tomcat Version 5.0.25
JDK Version 1.5
One of our vendor required client authentication to retrieve data. So, we
got a Thwate Freemail Certificate, send the vendor our serial number. Our
vendor added that serial number to their application to allow us to contact
their .aspx url.
We got the certificate .pfx file with the certificate chain. For our java
code to interact successfully with their URL, we had to import the
certificate with the private key in a keystore. We created a Keystore by
extracting the private key from the .pfx file. So every time we connect
using the httpsurl connection, we put the keystore as follows:
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.ssl.keyStorePassword", _storePwd);
System.setProperty("javax.net.ssl.keyStore", _keystorePath);
URL urlToConnect = new URL(_url);
HttpURLConnection conn = (HttpURLConnection)
urlToConnect.openConnection();
conn.setRequestMethod("POST");
conn.setDoOutput(true);
OutputStreamWriter wr;
wr = new OutputStreamWriter(conn.getOutputStream());
wr.write(_parameter);
wr.flush();
wr.close();
This works fine, when we are connecting through the code, no tomcat any
standalone application works fine. Even on our development machine tomcat
works fine in exchanging data with the vendor. On our development machine we
do not have IIS forwarding the request via redirector.
On our production its not working, somehow when we are sending the https
request, its not taking affect that the keystore is mentioned. Everytime
instead of the expected result we get an error page from them as follows:
Secure Channel Client
Authentication Required This Virtual Directory requires a browser that
supports the configured encryption options.
On the production servers, if we directly connect to tomcat via the http
port mentioned in the server.xml, bypassing the IIS, it works fine.
http://localhost:9001/ to test the connectivity to vendor.
When we put the IIS back in mixture, it does not work anymore.
When the http request comes from IIS to tomcat, and tomcat initiates the
httpsurlconnection to the URL specified, in this roundtrip to the vendor URL
no IIS is involved right? The IIS will forward any request meant for tomcat,
and the HTML generated by tomcat is forwarded back to IIS, is that the only
link between IIS and tomcat or they interact more?
When the java code executes, it only looks at the keystore specified
right? Does having the .pfx file imported with the cert chain in the
personal store matter to JAVA code?(On local machine I did delete the
certificate imported in the personal store and the java code still worked
fine.)
Thanks a lot for reading,
Rumpa Giri
---------------------------------
Feel free to call! Free PC-to-PC calls. Low rates on PC-to-Phone. Get
Yahoo! Messenger with Voice
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
