Punchout problem. CertificateException: Untrusted Cert Chain.

Hi all
I hope this is an appropriate forum. I am a developer at a company who has a web site that customers interact with via punchout. I developed the system some time ago. It has nothing to do with Oracle but we have a punchout customer who is converting from Ariba to Oracle. I guess I'm looking for any advice on what to do or what to tell the customer to help solve this problem. They seem to have run out of ideas.
Everything works well when they send a PunchoutSetupRequest cXML request but when they try to send an OrderRequest they get the following SSL error.
.apps.ecx.oxta.ConnectionFailureException: Connection failure resulting
from: javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: Untrusted Cert Chain
They're asking me whether am I handling the two types of requests differently but that question makes no sense at this level because it's the same https URL. I have no way of even knowing what type of cXML request is coming until the SSL handshake has succeeded.
We're running Microsoft IIS. Our SSL certificate has a cert chain back to Equifax. It works on all major browsers, Ariba and their Oracle PunchoutSetup request. I got them to try it with a browser and the SSL worked without error. I can see in my web log that they accessed it using Internet Explorer. I assume that the Oracle system is not running Windows so accessing it with Internet Explorer from a Windows machine might not have been very helpful.
They say to me that "it's the same site, same server" for the two types of documents. I assume they mean it's the same https client but how can that be true if the SSL succeeds on one type of document but fails on another?
I've just noticed that the UserAgent is different for the two requests. For PunchoutSetupRequest it's "Oracle iProcurement" but for OrderRequest it's "Oracle E-Business Suite Oracle Purchasing 11.5.9.". Does that mean they are different https clients? I only know the OrderRequest UserAgent because they emailed me an error message which included the cXML.
I know nothing about Oracle but it seems to me that someone at our customer site needs to do the equivalent of "Accept this certificate" which you can do with a browser assuming that they trust us. At one point they got me to send our certificate so I visited our site with a browser and exported the cert and sent it to them which they could have done themselves. It's not clear to me what they did with it but, coincidentally perhaps, the PunchoutSetupRequest also failed the SSL handshake until I sent them that.
The only solution may be for us to buy a different (more expensive) certificate but that seems unnecessary to me and they've been unable to answer my question "what signing authorities do you accept". I've been able to look at a couple of their other suppliers and their public sites use certs from GTE CyberTrust so I suspect their punchout site uses the same.
Any ideas or suggests would be appreciated.
Thanks

Hi,
Similar error is reported in the following documents, please see if it helps.
Note: 167474.1 - Oracle XML Gateway Troubleshooting Guide
Note: 152775.1 - Installing Oracle XML Gateway and Oracle Workflow with Oracle Applications 11i
Regards,
Hussein

Similar Messages

Java.security.cert.CertificateException: Untrusted Cert Chain

Hi all,
While sending transaction to our supplier I am facing below error, Actually Our trading partner has given .p7b cert, I converted it into base 64 and i m using in b2b server. I am doing the same with all the suppliers but I am facing issue with only this trading partner. I asked him to send a new trusted certificate but he said that he is having 100's of customers, all are using the same certficate.
Error
http.sender.timeout=0
2010.05.20 at 10:52:20:711: Thread-19: B2B - (DEBUG) scheme null userName null realm null
2010.05.20 at 10:52:22:159: Thread-19: B2B - (WARNING)
Message Transmission Transport Exception
Transport Error Code is OTA-HTTP-SEND-1006
StackTrace oracle.tip.transport.TransportException: [IPT_HttpSendHttpResponseError] HTTP response error :java.security.cert.CertificateException: Untrusted Cert Chain.
     at oracle.tip.transport.TransportException.create(TransportException.java:91)
     at oracle.tip.transport.basic.HTTPSender.send(HTTPSender.java:627)
     at oracle.tip.transport.b2b.B2BTransport.send(B2BTransport.java:311)
     at oracle.tip.adapter.b2b.transport.TransportInterface.send(TransportInterface.java:1034)
     at oracle.tip.adapter.b2b.msgproc.Request.outgoingRequestPostColab(Request.java:1758)
     at oracle.tip.adapter.b2b.msgproc.Request.outgoingRequest(Request.java:976)
     at oracle.tip.adapter.b2b.engine.Engine.processOutgoingMessage(Engine.java:1167)
     at oracle.tip.adapter.b2b.transport.AppInterfaceListener.onMessage(AppInterfaceListener.java:141)
     at oracle.tip.transport.basic.FileSourceMonitor.processMessages(FileSourceMonitor.java:903)
     at oracle.tip.transport.basic.FileSourceMonitor.run(FileSourceMonitor.java:317)
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted Cert Chain
     at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
     at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA12275)
     at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:112)
     at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:3018)
     at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2843)
     at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2635)
     at HTTPClient.HTTPConnection.Post(HTTPConnection.java:1107)
     at oracle.tip.transport.basic.HTTPSender.send(HTTPSender.java:590)
     ... 8 more
Caused by: java.security.cert.CertificateException: Untrusted Cert Chain
     at oracle.security.pki.ssl.C21.checkClientTrusted(C21)
     at oracle.security.pki.ssl.C21.checkServerTrusted(C21)
     at oracle.security.pki.ssl.C08.checkServerTrusted(C08)
     at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(DashoA12275)
     ... 21 more
2010.05.20 at 10:52:22:164: Thread-19: B2B - (DEBUG) oracle.tip.adapter.b2b.transport.TransportInterface:send Error in sending message
2010.05.20 at 10:52:22:168: Thread-19: B2B - (INFORMATION) oracle.tip.adapter.b2b.msgproc.Request:outgoingRequestPostColab Request Message Transmission failed
2010.05.20 at 10:52:22:170: Thread-19: B2B - (DEBUG) DBContext beginTransaction: Enter
2010.05.20 at 10:52:22:173: Thread-19: B2B - (DEBUG) DBContext beginTransaction: Transaction.begin()
2010.05.20 at 10:52:22:176: Thread-19: B2B - (DEBUG) DBContext beginTransaction: Leave
2010.05.20 at 10:52:22:179: Thread-19: B2B - (DEBUG) oracle.tip.adapter.b2b.msgproc.Request:outgoingRequestPostColab [IPT_HttpSendHttpResponseError] HTTP response error :java.security.cert.CertificateException: Untrusted Cert Chain.
Untrusted Cert Chain
2010.05.20 at 10:52:22:226: Thread-19: B2B - (DEBUG) oracle.tip.adapter.b2b.engine.Engine:notifyApp retry value <= 0, so sending exception to IP_IN_QUEUE
2010.05.20 at 10:52:22:232: Thread-19: B2B - (DEBUG) Engine:notifyApp Enter
2010.05.20 at 10:52:22:248: Thread-19: B2B - (DEBUG) notifyApp:notifyApp Enqueue the ip exception message:
<Exception xmlns="http://integration.oracle.com/B2B/Exception" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<correlationId>543222</correlationId>
<b2bMessageId>543222</b2bMessageId>
<errorCode>AIP-50079</errorCode>
<errorText>Transport error: [IPT_HttpSendHttpResponseError] HTTP response error :java.security.cert.CertificateException: Untrusted Cert Chain.
Untrusted Cert Chain</errorText>
<errorDescription>
<![CDATA[Machine Info: (usmtnz-sinfwi02)Transport error: [IPT_HttpSendHttpResponseError] HTTP response error :java.security.cert.CertificateException: Untrusted Cert Chain.
Untrusted Cert Chain ]]>
</errorDescription>
<errorSeverity>2</errorSeverity>
</Exception>
2010.05.20 at 10:52:22:298: Thread-19: B2B - (DEBUG) Engine:notifyApp Exit
2010.05.20 at 10:52:22:301: Thread-19: B2B - (DEBUG) DBContext commit: Enter
2010.05.20 at 10:52:22:307: Thread-19: B2B - (DEBUG) DBContext commit: Transaction.commit()
2010.05.20 at 10:52:22:310: Thread-19: B2B - (DEBUG) DBContext commit: Leave
2010.05.20 at 10:52:22:313: Thread-19: B2B - (DEBUG) oracle.tip.adapter.b2b.msgproc.Request:outgoingRequest Exit
2010.05.20 at 10:52:22:317: Thread-19: B2B - (INFORMATION) oracle.tip.adapter.b2b.engine.Engine:processOutgoingMessage:
***** REQUEST MESSAGE *****
Exchange Protocol: AS2 Version 1.1
Transport Protocol: HTTPS
Unique Message ID: <543222@EMRSNS>
Trading Partner: ZZEASY_PROD
Message Signed: RSA
Payload encrypted: 3DES
Attachment: None

Hi CNU,
1st they has given me in .p7b certificateIs it a self-signed certificate? If no then do you have the CA certs as well?
Open the certificate by double clicking on it. If "Issued To" and "Issued By" fields are same then it is a self signed cert and you need to import only this cert (in base64 format) into wallet.
If it is not a self-signed cert then open the certificate and click on "Certification Path" tab. You should be able to see the issue's certificate here. Make sure that you have imported all issuers certificate along with your TP's cert in the wallet. Moreover, check that all the certs (TP cert and it's issuer cert's) are valid in terms of dates. You can see the "Certificate status" in "Certification Path" tab of certificate.
Please provide the certificate chain details here along with list of certs in wallet (you may mail it to my id as well - [email protected])
Regards,
Anuj

Untrusted cert chains

Hi,
I have installed SSL 3 on my IIS server. Am trying to connect to the server with my java code. When i connect to the sever using HTTPSURLConnection it gives me this error. Then i imported the certificate of the server using keytool but still it was giving me the same error. No when i again try to import it it gives the error "KeyStore was tampered".
Can anyone please tell me what is the correct way to connect to the server using jsse.
thanX
-Vaijayanti

hi,
1. Make sure JSSE is installed properly.
2. Import the certificate in the keystore with the command
keytool -import -file "cert name" -keystore "c:\jdk1.3\jre\lib\security\cacerts"
2. U may get the problem while running the code if threre are more than one JRE installed. So there may be more than one cacerts file on ur machine and on runtime it may be picking the cacerts file from the wrong path.
3. Run the code. This is the sample code
System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
Security.addProvider(
new com.sun.net.ssl.internal.ssl.Provider());
     URL url = new URL("your url");
     HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
     BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));
     while ((inputLine = in.readLine()) != null)
     System.out.println(inputLine);
Try this. Hope this will help u. If if is giving error as keystore has tampered replace the cacerts with jssecacerts
-Vaijayanti

Untrusted Certificate Chain

Keep receiving Msg "you are attempting to open a secure connection, but the server's cert is not trusted". If I try to trust certificate it requires that I enter my key store password. I have no idea what that is. If I View the Certificate it says the program is "rcp.na.blackberry.com" with an untrusted cert chain - stale chain status - x 509. It stops popping up when I disconnect from my wifi, otherwise it keeps popping up at different times.

hello,
have you heard of "secured transaction" or "electronic signature" or "e-signing" or "SSL" ?
to make things short : when you browse the web, anyone can "do something" and be able to sniff what you send and what you receive.
When you log on the present forum, you do it with HTTP.
If your neighbor knows how, he/she can get the password you use to connect.
that is why people have created SSL. when you go to a secured website, like your bank website, or paypal, or amazon, you go to a page which URL starts with HTTPS:// instead of HTTP://
if your browser is up-to-date, something should change in the address bar : a color, a sign, a lock that is closed (even on your blackberry Browser).
HTTPS stands for HTTP over SSL. basically, SSL is a security tunnel.
when you use that SSL, nobody can get the information that you exchange with the webserver.
but the SSL protocol is something open : anyone can create an SSL key and say "hey, come and see me, my tunnel is secure". So you have to know who that person is. It is also done by something like SSL. It's called electronic certificates. Codename : X.509.
so a X.509 is a certificate that says "I am AAA and I can do BBB !".
how can you trust that certificate ? Because it is certified by a higher authority (a private one, not necessarily government). You know these authorities. They appear on the bottom of your bank websites :
Verisign
Thawte
Certicom (cough cough cough)
CertPlus
RSA (the SecurID !)
VISA (the credit card !)
and so on...
these are very valuable Certificate Authorities (CA) that you can trust. But how can you, since you may have never heard of them ?
well, RIM does that for you, just like any browser system does.
When you look at your Windows system, you will see all those CA in the list, as well as others like AOL or Dell or Microsoft.
On your BlackBerry system, it's the same : RIM has put trust in those CAs.
Those CAs are stored somewhere on your device, in a place called the KeyStore.
The problem comes when you log on to a website, that uses HTTPS, and whose X.509 certificate is certified by a CA that is not present on your device.
therefore, the certificate is valid, but not trusted by your browser.
you are saying the CA is rcp.na.blackberry.com : that is quite strange actually. What website are you trying to log on ?
The search box on top-right of this page is your true friend, and the public Knowledge Base too:

JSSE Client and server communication problem .err:untrusted server cert

Hai all,
I am trying to communicate JSSE client and server.
I have created root.cert(CA),root.key,server.cert,server.key , client.cert and client.key. All these certificates are created using openssl.
I have placed root.cert in default keystore cacerts.
I have created a keystores(server & client) name mykeystore.
I have placed root.cert and client.cert in the client keystore.
I have placed root.cert and server.cert in the server keystore.
But during the run time i am getting javax.net.ssl.SSLException: untrusted server cert chain.
please suggest the modifications needs to be done to fix the error.
please tell me In the client keystore and in the server keystore....what certificates we need to put?
whether my approach as said above is correct or not?
In java code how to specify this particular certificate we are referring?
I have coded in this way ....
SSLContext ctx;
KeyManagerFactory kmf;
KeyStore ks;
char[] prasad = "prasad".toCharArray();
ctx = SSLContext.getInstance("SSLv3");
kmf = KeyManagerFactory.getInstance("SunX509");
ks = KeyStore.getInstance("jks");
ks.load(new FileInputStream("mykeystore"), prasad);
kmf.init(ks, prasad);
ctx.init(kmf.getKeyManagers(), null, null);
factory = ctx.getSocketFactory();
But my doubt is we are specifying only keystore name with that how it will check root.cert(ca) and client.cert and server.cert?
Is there any modifications need in my code?
Please tell me some way ...
Thanks ,
Prasad.

Hi prasad,
There will be a problem with the certificates being received from thr remote server or client. Check that your trust store contains the certificate of the remote machine or the CA that signed it and that the certificate has not expired.
Also be sure that both machines are using the latest version of the JSSE.
Hope this will help you.
Regards,
Anil.
Technical Support Engineer.

Synchronization Error: Untrusted Server Cert Chain

Hi Folks,
The basis team have installed SAP Netweaver 7.01 with Mobile 7.1 on the server. I'm using the NW Mobile Client on a Hand Held to synchronize and register for the first time to the DOE. But I'm getting the error: "Untrusted Server Cert Chain".
Can anyone guide me through this problem. I know that this is something with a certificate but still don't know how solve this.
Thanks in advance.
Regards,
Gilberto Li

Solved it with OSS Note 550498.

Help - untrusted server cert chain again !!!

Hi,
I dont understand what's wrong, I have a cert file(pnew.p12) which can be used talking to secure server via browser with no problem(do it means it been signed by my CA already?).
then I try to do it in JSSE.
First, I export to Base64 cer format file called mycert.cer.
then, I create truststore use:
keytool -import -alias mycert -keystore mytrust -storepass 111111 -trustcacerts
Then, In my code, I read this truststore and key file from original cer file(pnew.p12)
-------- my test.java code ----------
KeyManagerFactory kmf;
TrustManagerFactory tmf;
KeyStore ts;
char[] passphrase = "111111".toCharArray();
char[] passphrase1 = "222222".toCharArray();
ctx = SSLContext.getInstance("TLS");
kmf = KeyManagerFactory.getInstance("SunX509");
tmf = TrustManagerFactory.getInstance("SunX509");
ts = KeyStore.getInstance("JKS");
KeyStore ks=KeyStore.getInstance("PKCS12");
ts.load(new FileInputStream("mytrust"), passphrase);
ks.load(new FileInputStream("pnew.p12"), passphrase1);
tmf.init(ts);
kmf.init(ks, passphrase1);
ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
factory = ctx.getSocketFactory();
I know steps which be used to talk to server as follow:
1. Client hello
2. Server hello
3. Certificate (Optional)
4. Certificate request (Optional)
5. Server key exchange (Optional)
6. Server hello done
7. Certificate (Optional)
8. Client key exchange
9. Certificate verify (Optional)
10. Change cipher spec
11. Finished
12. Change cipher spec
13. Finished
14. Encrypted data
I also know what's this error means, but I still cant figure out how to fix it(it is no system clock problem). can someone give me some ideas? or do I need to require any cert from guy who hosting secure server?
C:\jdk1.4\demo\jsse\sockets\client>java -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol -Djavax.net.debug=ssl test adding as trusted cert: [
Version: V1
Subject: OID.2.5.4.5=14 + CN=EIS secure-Test2 + [email protected], DNQ=TRL Demo Customer, C=AU
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@31c260
Validity: [From: Mon Jan 01 11:00:00 EST 2001,
               To: Thu Jan 01 10:59:59 EST 2004]
Issuer: OU=Prototype Research CA, O=secure Research Laboratories, C=AU
SerialNumber: [    260e]
Algorithm: [MD5withRSA]
Signature:
0000: 24 3F 01 69 AB 6B 9A B8 CD 92 AA 8A FF 11 7F 9D $?.i.k..........
0010: 0F 5E 20 3A 43 8C 58 F9 8C 14 28 00 FE 2A 52 95 .^ :C.X...(..*R.
0020: 86 62 3A 5D 6D 17 60 DF 67 4A 6D 83 8C EF 8E 12 .b:]m.`.gJm.....
0030: D0 84 68 03 AC C1 41 28 4F 0A E6 CA 02 38 DF E1 ..h...A(O....8..
0040: 6C 96 8E C0 74 65 F7 07 DA 57 5C 79 53 FF 23 AA l...te...W\yS.#.
0050: D3 E3 1F E7 D8 C8 92 5D B2 3B FC 30 EE 26 6A B8 .......].;.0.&j.
found key for : eis secure-test2's secure research laboratories id
trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 993449488 bytes = { 225, 246, 212, 140, 222, 64, 204, 172, 19, 68, 80, 74, 158, 218, 215, 169, 231, 97, 88, 0, 198, 89, 193, 202, 247, 137, 137, 130 }
Session ID: {}
Cipher Suites: { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods: { 0 }
[write] MD5 and SHA1 hashes: len = 59
0000: 01 00 00 37 03 01 3B 37 D6 10 E1 F6 D4 8C DE 40 ...7..;7.......@
0010: CC AC 13 44 50 4A 9E DA D7 A9 E7 61 58 00 C6 59 ...DPJ.....aX..Y
0020: C1 CA F7 89 89 82 00 00 10 00 05 00 04 00 09 00 ................
0030: 0A 00 12 00 13 00 03 00 11 01 00 ...........
main, WRITE: SSL v3.1 Handshake, length = 59
[write] MD5 and SHA1 hashes: len = 77
0000: 01 03 01 00 24 00 00 00 20 00 00 05 00 00 04 01 ....$... .......
0010: 00 80 00 00 09 06 00 40 00 00 0A 07 00 C0 00 00 .......@........
0020: 12 00 00 13 00 00 03 02 00 80 00 00 11 3B 37 D6 .............;7.
0030: 10 E1 F6 D4 8C DE 40 CC AC 13 44 50 4A 9E DA D7 [email protected]...
0040: A9 E7 61 58 00 C6 59 C1 CA F7 89 89 82 ..aX..Y......
main, WRITE: SSL v2, contentType = 22, translated length = 16310
main, READ: SSL v3.0 Handshake, length = 3032
*** ServerHello, v3.0
RandomCookie: GMT: -1000857547 bytes = { 206, 49, 99, 167, 24, 34, 141, 105, 218, 92, 156, 73, 140, 60, 97, 32, 107, 172, 35, 105, 10, 147, 126, 37, 232, 221, 67, 208 }
Session ID: {1, 79, 211, 81, 55, 204, 160, 210, 64, 200, 49, 173, 91, 16, 107, 40, 145, 101, 201, 32, 79, 56, 236, 96, 11, 122, 223, 205, 2, 137, 193, 165}
Cipher Suite: { 0, 4 }
Compression Method: 0
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 00 C4 58 20 35 CE 31 63 A7 18 22 ...F...X 5.1c.."
0010: 8D 69 DA 5C 9C 49 8C 3C 61 20 6B AC 23 69 0A 93 .i.\.I.<a k.#i..
0020: 7E 25 E8 DD 43 D0 20 01 4F D3 51 37 CC A0 D2 40 .%..C. .O.Q7...@
0030: C8 31 AD 5B 10 6B 28 91 65 C9 20 4F 38 EC 60 0B .1.[.k(.e. O8.`.
0040: 7A DF CD 02 89 C1 A5 00 04 00 z.........
*** Certificate chain
chain [0] = [
Version: V3
Subject: CN=pocketnews.secure.com, OU=OnAir, O=secure, L=Sydney, ST=NSW, C=AU
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@38e059
Validity: [From: Fri Aug 18 10:00:00 EST 2000,
               To: Sun Aug 19 09:59:59 EST 2001]
Issuer: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust Network
SerialNumber: [    6a2bcc17 0d6f8a04 1c49aa2d 84464c3e ]
Certificate Extensions: 4
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL server
[2]: ObjectId: 2.5.29.3 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 82 02 16 30 82 02 12 30 82 02 0E 30 82 02 0A ....0...0...0...
0010: 06 0B 60 86 48 01 86 F8 45 01 07 01 01 30 82 01 ..`.H...E....0..
0020: F9 16 82 01 A7 54 68 69 73 20 63 65 72 74 69 66 .....This certif
0030: 69 63 61 74 65 20 69 6E 63 6F 72 70 6F 72 61 74 icate incorporat
0040: 65 73 20 62 79 20 72 65 66 65 72 65 6E 63 65 2C es by reference,
0050: 20 61 6E 64 20 69 74 73 20 75 73 65 20 69 73 20 and its use is
0060: 73 74 72 69 63 74 6C 79 20 73 75 62 6A 65 63 74 strictly subject
0070: 20 74 6F 2C 20 74 68 65 20 56 65 72 69 53 69 67 to, the VeriSig
0080: 6E 20 43 65 72 74 69 66 69 63 61 74 69 6F 6E 20 n Certification
0090: 50 72 61 63 74 69 63 65 20 53 74 61 74 65 6D 65 Practice Stateme
00A0: 6E 74 20 28 43 50 53 29 2C 20 61 76 61 69 6C 61 nt (CPS), availa
00B0: 62 6C 65 20 61 74 3A 20 68 74 74 70 73 3A 2F 2F ble at: https://
00C0: 77 77 77 2E 76 65 72 69 73 69 67 6E 2E 63 6F 6D www.verisign.com
00D0: 2F 43 50 53 3B 20 62 79 20 45 2D 6D 61 69 6C 20 /CPS; by E-mail
00E0: 61 74 20 43 50 53 2D 72 65 71 75 65 73 74 73 40 at CPS-requests@
00F0: 76 65 72 69 73 69 67 6E 2E 63 6F 6D 3B 20 6F 72 verisign.com; or
0100: 20 62 79 20 6D 61 69 6C 20 61 74 20 56 65 72 69 by mail at Veri
0110: 53 69 67 6E 2C 20 49 6E 63 2E 2C 20 32 35 39 33 Sign, Inc., 2593
0120: 20 43 6F 61 73 74 20 41 76 65 2E 2C 20 4D 6F 75 Coast Ave., Mou
0130: 6E 74 61 69 6E 20 56 69 65 77 2C 20 43 41 20 39 ntain View, CA 9
0140: 34 30 34 33 20 55 53 41 20 54 65 6C 2E 20 2B 31 4043 USA Tel. +1
0150: 20 28 34 31 35 29 20 39 36 31 2D 38 38 33 30 20 (415) 961-8830
0160: 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 31 39 Copyright (c) 19
0170: 39 36 20 56 65 72 69 53 69 67 6E 2C 20 49 6E 63 96 VeriSign, Inc
0180: 2E 20 20 41 6C 6C 20 52 69 67 68 74 73 20 52 65 . All Rights Re
0190: 73 65 72 76 65 64 2E 20 43 45 52 54 41 49 4E 20 served. CERTAIN
01A0: 57 41 52 52 41 4E 54 49 45 53 20 44 49 53 43 4C WARRANTIES DISCL
01B0: 41 49 4D 45 44 20 61 6E 64 20 4C 49 41 42 49 4C AIMED and LIABIL
01C0: 49 54 59 20 4C 49 4D 49 54 45 44 2E A0 0E 06 0C ITY LIMITED.....
01D0: 60 86 48 01 86 F8 45 01 07 01 01 01 A1 0E 06 0C `.H...E.........
01E0: 60 86 48 01 86 F8 45 01 07 01 01 02 30 2C 30 2A `.H...E.....0,0*
01F0: 16 28 68 74 74 70 73 3A 2F 2F 77 77 77 2E 76 65 .(https://www.ve
0200: 72 69 73 69 67 6E 2E 63 6F 6D 2F 72 65 70 6F 73 risign.com/repos
0210: 69 74 6F 72 79 2F 43 50 53 20 itory/CPS
[3]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
[2.16.840.1.113730.4.1]]
[4]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
Algorithm: [MD5withRSA]
Signature:
0000: CF EE E8 78 F8 75 6A 6F F9 B0 7C B9 33 F2 D0 8C ...x.ujo....3...
0010: 5D 88 B7 A8 42 89 87 D9 76 50 9B 0C E3 9C 05 2A ]...B...vP.....*
0020: 6D 0E 25 7A 5F 2D 07 EE AF 1F 73 05 93 BF EE 65 m.%z_-....s....e
0030: D7 E7 97 CD EA EE 6D 11 EF 0C 48 67 18 A4 B0 03 ......m...Hg....
0040: F4 A3 1B 2E EA 14 9C 56 5A 98 BF 2F AD 4B 50 4A .......VZ../.KPJ
0050: 21 8E 0F DA 4A DE 4E 82 53 FB BF F2 B8 D4 AD 2A !...J.N.S......*
0060: B8 DC C1 9B 2C A9 96 66 12 D9 5A 97 AB 3D 1C 5C ....,..f..Z..=.\
0070: 24 25 1C 0A 2E 08 F6 0A 26 E0 7E D5 36 76 00 90 $%......&...6v..
chain [1] = [
Version: V3
Subject: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust Network
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@15c083
Validity: [From: Thu Apr 17 10:00:00 EST 1997,
               To: Thu Jan 08 10:59:59 EST 2004]
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
SerialNumber: [    236c971e 2bc60d0b f97460de f108c3c3 ]
Certificate Extensions: 5
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL CA
S/MIME CA
[2]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [2.16.840.1.113733.1.7.1.1]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.1
qualifier: 0000: 16 1C 68 74 74 70 73 3A   2F 2F 77 77 77 2E 76 65 ..https://www.ve
0010: 72 69 73 69 67 6E 2E 63   6F 6D 2F 43 50 53        risign.com/CPS
], PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.2
qualifier: 0000: 30 81 D9 30 15 16 0E 56 65 72 69 53 69 67 6E 2C 0..0...VeriSign,
0010: 20 49 6E 63 2E 30 03 02 01 01 1A 81 BF 56 65 72 Inc.0.......Ver
0020: 69 53 69 67 6E 27 73 20 43 65 72 74 69 66 69 63 iSign's Certific
0030: 61 74 69 6F 6E 20 50 72 61 63 74 69 63 65 20 53 ation Practice S
0040: 74 61 74 65 6D 65 6E 74 2C 20 77 77 77 2E 76 65 tatement, www.ve
0050: 72 69 73 69 67 6E 2E 63 6F 6D 2F 43 50 53 2C 20 risign.com/CPS,
0060: 67 6F 76 65 72 6E 73 20 74 68 69 73 20 63 65 72 governs this cer
0070: 74 69 66 69 63 61 74 65 20 26 20 69 73 20 69 6E tificate & is in
0080: 63 6F 72 70 6F 72 61 74 65 64 20 62 79 20 72 65 corporated by re
0090: 66 65 72 65 6E 63 65 20 68 65 72 65 69 6E 2E 20 ference herein.
00A0: 53 4F 4D 45 20 57 41 52 52 41 4E 54 49 45 53 20 SOME WARRANTIES
00B0: 44 49 53 43 4C 41 49 4D 45 44 20 26 20 4C 49 41 DISCLAIMED & LIA
00C0: 42 49 4C 49 54 59 20 4C 54 44 2E 20 28 63 29 31 BILITY LTD. (c)1
00D0: 39 39 37 20 56 65 72 69 53 69 67 6E 997 VeriSign
[3]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
[2.16.840.1.113733.1.8.1, 2.16.840.1.113730.4.1]]
[4]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
Key_CertSign
Crl_Sign
[5]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:0
Algorithm: [MD2withRSA]
Signature:
0000: B8 8C 98 C3 2B 48 F5 72 CD 68 0D 1A B3 74 63 BB ....+H.r.h...tc.
0010: B1 58 B6 98 45 22 EC 11 8D C7 4E 33 8B 62 5A 21 .X..E"....N3.bZ!
0020: 24 6C 9A C0 42 B4 45 A9 3A FB 67 F0 91 BE 18 1F $l..B.E.:.g.....
0030: D5 48 19 93 6B 8D CB 37 4B 86 E6 7D 9B FD 8C 78 .H..k..7K......x
0040: 99 FF 83 C2 FC D9 55 06 9E 31 66 46 7D 1B 78 60 ......U..1fF..x`
0050: F4 55 D4 6C 55 C8 69 62 70 7C 4D B6 89 06 05 9B .U.lU.ibp.M.....
0060: C8 43 8E CC 0C 28 D5 D1 8C CD 46 50 E3 31 96 66 .C...(....FP.1.f
0070: 92 11 24 1E 4A 5B 4B 66 5E 65 55 1E 5F 37 9A AE ..$.J[Kf^eU._7..
chain [2] = [
Version: V1
Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@2d9c06
Validity: [From: Mon Jan 29 11:00:00 EST 1996,
               To: Sat Jan 01 10:59:59 EST 2000]
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
SerialNumber: [    02a10000 01]
Algorithm: [MD2withRSA]
Signature:
0000: 75 66 6C 3E D1 CD 81 DB B5 F8 2F 36 51 B6 F7 42 ufl>....../6Q..B
0010: BC CD 42 AF DC 0E FA 15 6C F8 67 93 57 3A EB B6 ..B.....l.g.W:..
0020: 92 E8 B6 01 CA 8C B7 8E 43 B4 49 65 F9 3E EE BD ........C.Ie.>..
0030: 75 46 2E C9 FC 25 5D A8 C7 2F 8B 9B 8F 68 CF B4 uF...%]../...h..
0040: 9C 97 18 C0 4D EF 1F D9 AF 82 B3 E6 64 B8 84 5C ....M.......d..\
0050: 8A 9A 07 52 43 61 FB 74 9E 5B 3A 36 FC 4C B2 FC ...RCa.t.[:6.L..
0060: 1A 3F 15 2E A5 5B 3C 1B 90 EC 88 29 E4 59 16 F9 .?...[<....).Y..
0070: CE 07 AD EC E9 DD DA D2 31 8A 4F D6 D8 EF 17 8D ........1.O.....
out of date cert: [
Version: V1
Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@2d9c06
Validity: [From: Mon Jan 29 11:00:00 EST 1996,
               To: Sat Jan 01 10:59:59 EST 2000]
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
SerialNumber: [    02a10000 01]
Algorithm: [MD2withRSA]
Signature:
0000: 75 66 6C 3E D1 CD 81 DB B5 F8 2F 36 51 B6 F7 42 ufl>....../6Q..B
0010: BC CD 42 AF DC 0E FA 15 6C F8 67 93 57 3A EB B6 ..B.....l.g.W:..
0020: 92 E8 B6 01 CA 8C B7 8E 43 B4 49 65 F9 3E EE BD ........C.Ie.>..
0030: 75 46 2E C9 FC 25 5D A8 C7 2F 8B 9B 8F 68 CF B4 uF...%]../...h..
0040: 9C 97 18 C0 4D EF 1F D9 AF 82 B3 E6 64 B8 84 5C ....M.......d..\
0050: 8A 9A 07 52 43 61 FB 74 9E 5B 3A 36 FC 4C B2 FC ...RCa.t.[:6.L..
0060: 1A 3F 15 2E A5 5B 3C 1B 90 EC 88 29 E4 59 16 F9 .?...[<....).Y..
0070: CE 07 AD EC E9 DD DA D2 31 8A 4F D6 D8 EF 17 8D ........1.O.....
main, SEND SSL v3.0 ALERT: fatal, description = certificate_unknown
main, WRITE: SSL v3.0 Alert, length = 2
javax.net.ssl.SSLHandshakeException: untrusted server cert chain
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.ClientHandshaker.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.Handshaker.process_record([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
at java.io.OutputStream.write(OutputStream.java:61)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
at test.main(test.java:82)

Hi david,
I am also having the same problem. Below is my debug message. If possible pl. tell me what you did to fix the problem.
Debug.
*** ClientHello, v3.1
[write] MD5 and SHA1 hashes: len = 47
0000: 01 00 00 2B 03 01 3B 6F 8A 74 C3 88 A3 70 1F F6 ...+..;o.t...p..
0010: 86 9F F7 50 66 12 1C BF 9A 0D 5F ED 20 F4 07 52 ...Pf....._. ..R
0020: 17 A7 6A 1B 10 8C 00 00 04 00 03 00 11 01 00 ..j............
[write] MD5 and SHA1 hashes: len = 50
0000: 01 03 01 00 09 00 00 00 20 00 00 03 02 00 80 00 ........ .......
0010: 00 11 3B 6F 8A 74 C3 88 A3 70 1F F6 86 9F F7 50 ..;o.t...p.....P
0020: 66 12 1C BF 9A 0D 5F ED 20 F4 07 52 17 A7 6A 1B f....._. ..R..j.
0030: 10 8C ..
*** ServerHello, v3.0
** SSL_RSA_EXPORT_WITH_RC4_40_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 00 3B 70 1F 94 E6 2C 62 7F 14 9E ...F..;p...,b...
0010: C2 AE 2A B9 56 DE 49 B7 6D 1F 24 45 38 45 5F DA ..*.V.I.m.$E8E_.
0020: AE CB C5 7F 05 9F 20 3B 70 1F 94 E3 5E E5 BC 17 ...... ;p...^...
0030: 18 7D FE CE B3 9D F6 37 27 05 9D 3F 8C D2 82 16 .......7'..?....
0040: 6F 3C 55 84 9E 9A A5 00 03 00 o<U.......
*** Certificate chain
[read] MD5 and SHA1 hashes: len = 1021
0000: 0B 00 03 F9 00 03 F6 00 01 F8 30 82 01 F4 30 82 ..........0...0.
0010: 01 9E 02 01 00 30 0D 06 09 2A 86 48 86 F7 0D 01 .....0...*.H....
0020: 01 04 05 00 30 81 84 31 0B 30 09 06 03 55 04 06 ....0..1.0...U..
0030: 13 02 49 4E 31 0B 30 09 06 03 55 04 08 13 02 54 ..IN1.0...U....T
0040: 4E 31 10 30 0E 06 03 55 04 07 13 07 43 48 45 4E N1.0...U....CHEN
0050: 4E 41 49 31 0D 30 0B 06 03 55 04 0A 13 04 41 32 NAI1.0...U....A2
0060: 57 49 31 0C 30 0A 06 03 55 04 0B 13 03 44 45 56 WI1.0...U....DEV
0070: 31 0D 30 0B 06 03 55 04 03 13 04 41 32 57 49 31 1.0...U....A2WI1
0080: 2A 30 28 06 09 2A 86 48 86 F7 0D 01 09 01 16 1B *0(..*.H........
0090: 61 64 6D 69 6E 69 73 74 72 61 74 6F 72 40 61 69 administrator@ai
00A0: 72 32 77 65 62 2E 63 6F 2E 69 6E 30 1E 17 0D 30 r2web.co.in0...0
00B0: 31 30 33 30 38 32 33 31 32 32 37 5A 17 0D 30 32 10308231227Z..02
00C0: 30 33 30 38 32 33 31 32 32 37 5A 30 81 84 31 0B 0308231227Z0..1.
00D0: 30 09 06 03 55 04 06 13 02 49 4E 31 0B 30 09 06 0...U....IN1.0..
00E0: 03 55 04 08 13 02 54 4E 31 10 30 0E 06 03 55 04 .U....TN1.0...U.
00F0: 07 13 07 43 48 45 4E 4E 41 49 31 0D 30 0B 06 03 ...CHENNAI1.0...
0100: 55 04 0A 13 04 41 32 57 49 31 0C 30 0A 06 03 55 U....A2WI1.0...U
0110: 04 0B 13 03 44 45 56 31 0D 30 0B 06 03 55 04 03 ....DEV1.0...U..
0120: 13 04 41 32 57 49 31 2A 30 28 06 09 2A 86 48 86 ..A2WI1*0(..*.H.
0130: F7 0D 01 09 01 16 1B 61 64 6D 69 6E 69 73 74 72 .......administr
0140: 61 74 6F 72 40 61 69 72 32 77 65 62 2E 63 6F 2E [email protected].
0150: 69 6E 30 5C 30 0D 06 09 2A 86 48 86 F7 0D 01 01 in0\0...*.H.....
0160: 01 05 00 03 4B 00 30 48 02 41 00 D6 44 43 83 68 ....K.0H.A..DC.h
0170: 77 B8 8B 05 FC 06 16 50 51 D7 66 91 7E 2C 13 FE w......PQ.f..,..
0180: 18 F4 64 9A 81 9F B2 EA CE 11 21 7F 4B B6 0B 41 ..d.......!.K..A
0190: 31 CE C1 90 5C 24 90 F8 A5 B8 9D 00 A8 81 59 17 1...\$........Y.
01A0: D4 CB 32 FC 43 DB D8 7A 06 6C 43 02 03 01 00 01 ..2.C..z.lC.....
01B0: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 03 0...*.H.........
01C0: 41 00 A3 FF F8 4B 49 B0 77 4E F8 8E 9D A1 99 58 A....KI.wN.....X
01D0: 65 3E 39 E4 7D BD 33 67 47 62 7B CE EC 9D 2B FB e>9...3gGb....+.
01E0: 59 F6 8D C6 BE 75 9F FE 17 C6 EB A8 77 36 40 F9 Y....u......w6@.
01F0: 49 19 8B 83 60 CE 43 73 90 0D BA 2A 30 98 93 EF I...`.Cs...*0...
0200: FF 6F 00 01 F8 30 82 01 F4 30 82 01 9E 02 01 00 .o...0...0......
0210: 30 0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 0...*.H........0
0220: 81 84 31 0B 30 09 06 03 55 04 06 13 02 49 4E 31 ..1.0...U....IN1
0230: 0B 30 09 06 03 55 04 08 13 02 54 4E 31 10 30 0E .0...U....TN1.0.
0240: 06 03 55 04 07 13 07 43 48 45 4E 4E 41 49 31 0D ..U....CHENNAI1.
0250: 30 0B 06 03 55 04 0A 13 04 41 32 57 49 31 0C 30 0...U....A2WI1.0
0260: 0A 06 03 55 04 0B 13 03 44 45 56 31 0D 30 0B 06 ...U....DEV1.0..
0270: 03 55 04 03 13 04 41 32 57 49 31 2A 30 28 06 09 .U....A2WI1*0(..
0280: 2A 86 48 86 F7 0D 01 09 01 16 1B 61 64 6D 69 6E *.H........admin
0290: 69 73 74 72 61 74 6F 72 40 61 69 72 32 77 65 62 istrator@air2web
02A0: 2E 63 6F 2E 69 6E 30 1E 17 0D 30 31 30 33 30 38 .co.in0...010308
02B0: 32 33 31 32 32 37 5A 17 0D 30 32 30 33 30 38 32 231227Z..0203082
02C0: 33 31 32 32 37 5A 30 81 84 31 0B 30 09 06 03 55 31227Z0..1.0...U
02D0: 04 06 13 02 49 4E 31 0B 30 09 06 03 55 04 08 13 ....IN1.0...U...
02E0: 02 54 4E 31 10 30 0E 06 03 55 04 07 13 07 43 48 .TN1.0...U....CH
02F0: 45 4E 4E 41 49 31 0D 30 0B 06 03 55 04 0A 13 04 ENNAI1.0...U....
0300: 41 32 57 49 31 0C 30 0A 06 03 55 04 0B 13 03 44 A2WI1.0...U....D
0310: 45 56 31 0D 30 0B 06 03 55 04 03 13 04 41 32 57 EV1.0...U....A2W
0320: 49 31 2A 30 28 06 09 2A 86 48 86 F7 0D 01 09 01 I1*0(..*.H......
0330: 16 1B 61 64 6D 69 6E 69 73 74 72 61 74 6F 72 40 ..administrator@
0340: 61 69 72 32 77 65 62 2E 63 6F 2E 69 6E 30 5C 30 air2web.co.in0\0
0350: 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 4B ...*.H.........K
0360: 00 30 48 02 41 00 D6 44 43 83 68 77 B8 8B 05 FC .0H.A..DC.hw....
0370: 06 16 50 51 D7 66 91 7E 2C 13 FE 18 F4 64 9A 81 ..PQ.f..,....d..
0380: 9F B2 EA CE 11 21 7F 4B B6 0B 41 31 CE C1 90 5C .....!.K..A1...\
0390: 24 90 F8 A5 B8 9D 00 A8 81 59 17 D4 CB 32 FC 43 $........Y...2.C
03A0: DB D8 7A 06 6C 43 02 03 01 00 01 30 0D 06 09 2A ..z.lC.....0...*
03B0: 86 48 86 F7 0D 01 01 04 05 00 03 41 00 A3 FF F8 .H.........A....
03C0: 4B 49 B0 77 4E F8 8E 9D A1 99 58 65 3E 39 E4 7D KI.wN.....Xe>9..
03D0: BD 33 67 47 62 7B CE EC 9D 2B FB 59 F6 8D C6 BE .3gGb....+.Y....
03E0: 75 9F FE 17 C6 EB A8 77 36 40 F9 49 19 8B 83 60 [email protected]...`
03F0: CE 43 73 90 0D BA 2A 30 98 93 EF FF 6F .Cs...*0....o
[read] MD5 and SHA1 hashes: len = 145
0000: 0D 00 00 8D 01 01 00 89 00 87 30 81 84 31 0B 30 ..........0..1.0
0010: 09 06 03 55 04 06 13 02 49 4E 31 0B 30 09 06 03 ...U....IN1.0...
0020: 55 04 08 13 02 54 4E 31 10 30 0E 06 03 55 04 07 U....TN1.0...U..
0030: 13 07 43 48 45 4E 4E 41 49 31 0D 30 0B 06 03 55 ..CHENNAI1.0...U
0040: 04 0A 13 04 41 32 57 49 31 0C 30 0A 06 03 55 04 ....A2WI1.0...U.
0050: 0B 13 03 44 45 56 31 0D 30 0B 06 03 55 04 03 13 ...DEV1.0...U...
0060: 04 41 32 57 49 31 2A 30 28 06 09 2A 86 48 86 F7 .A2WI1*0(..*.H..
0070: 0D 01 09 01 16 1B 61 64 6D 69 6E 69 73 74 72 61 ......administra
0080: 74 6F 72 40 61 69 72 32 77 65 62 2E 63 6F 2E 69 [email protected]
0090: 6E n
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
main, SEND SSL v3.0 ALERT: warning, description = no_certificate
*** ClientKeyExchange, RSA PreMasterSecret, v3.0
[write] MD5 and SHA1 hashes: len = 68
0000: 10 00 00 40 0C C4 88 95 C5 C9 2F 46 EF B9 EF EA ...@....../F....
0010: AB C5 46 E2 38 4F 4A CA 19 D8 08 8D 36 70 2B 7D ..F.8OJ.....6p+.
0020: 7F 8E 05 71 29 57 69 7B B2 6E 0C ED 61 03 DB 41 ...q)Wi..n..a..A
0030: F1 1A F0 94 AC F0 23 C8 E4 15 60 E2 47 14 A9 3E ......#...`.G..>
0040: 73 14 D3 C8 s...
main, WRITE: SSL v3.0 Change Cipher Spec, length = 1
*** Finished, v3.0
[write] MD5 and SHA1 hashes: len = 40
0000: 14 00 00 24 EC 0F 78 6D 4E 96 70 8D AB 0E 2F 6F ...$..xmN.p.../o
0010: 24 59 2F AF E4 66 9B DE 65 2C 23 E0 2E B5 DB 15 $Y/..f..e,#.....
0020: B8 9B 30 A6 E4 B8 4F 7F ..0...O.
*** Finished, v3.0
[read] MD5 and SHA1 hashes: len = 40
0000: 14 00 00 24 98 0E E7 1C 54 D8 BE B3 3D 23 4C 65 ...$....T...=#Le
0010: E9 B2 24 81 F6 F0 63 92 EB 92 8C 50 64 94 1F 04 ..$...c....Pd...
0020: 7D 27 25 C4 19 F1 C8 A7 .'%.....
main, RECV SSLv3 ALERT: warning, close_notify
main, SEND SSL v3.0 ALERT: warning, description = close_notify

Another untrusted server cert chain question

I have two servlets that make SSL connections to other servers and they seem to conflict with each other. The first servlet creates an SSL using a self-signed certificate that is imported programatically then used to make the connection:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("javax.net.ssl.truststore", "<path>\cert");
LDAPJSSESecureSocketFactory ldapjssesecuresocketfactory = new LDAPJSSESecureSocketFactory();
LDAPConnection ldapconnection = new LDAPConnection(ldapjssesecuresocketfactory);
The second servlet makes opens an SSL socket to a server using a Verisign-signed certificate, which desn't require any imported certificates:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
SSLSocketFactory factory = (SSLSocketFactory)SSLSocketFactory.getDefault();
socket = (SSLSocket)factory.createSocket("<URL>", 443);
When each is run independently they both work perfect but when you run the first before the second, the second returns:
I/O error javax.net.ssl.SSLException: untrusted server cert chain
I have tried importing the cert used in the first servet into the cacerts but it says it is not x.509 (and fails).
I have tried programatically importing the cacerts into the truststore in the second servlet but get the same untrusted server cert chain error.
Any assistance will be greatly appreciate.

Well, I answered my own problem and now everything is working. Since the main problem was that I could not import the certificate into the cacerts file (error: not x.509 format), I concentrated on that. Even though the server with the self-signed key is not a web server, I used IE to browse to https://<server>:<port>. When given the security prompt, I imported the certificate into IE. I then exported the same certificate in an x.509 standard. From there importing the certificate was text book:
keytool -import -trustcacert -alias <certalias> -file <path><certname> -keystore <javahome>\lib\security\cacerts
Hope this helps someone else :-)

Untrusted server cert chain - MI 7.1 Client PDA

Dear Expert,
I am implementing SSL security in SAP MI 7.1.
The HTTPS service is already enabled (port 443) and I can enter on via browser.
Generate a certificate and signed by the SAP test certificate for 8 weeks.
Export the certificate to the truststore file, using the command:
keytool -import -file MID.cer -keystore truststore -alias MID -storepass access
Copy the truststore file (whit certificate MID) in PDA: \MI\settings.
And also enable the parameters (in configuration.properties ):
com.sap.tc.mobile.sync.http.port=443
com.sap.tc.mobile.sync.protocol=https
com.sap.tc.mobile.sync.http.sslenabled=true
com.sap.tc.mobile.sync.https.hostnameverifying=false
com.sap.tc.mobile.sync.https.truststore=/MI/settings/truststore
But in trying to synchronize the PDA with the DOE get an error: "untrusted server cert chain"
I am using: Client MI 7.1 for PDA SP9
I have reviewed the documents: "How To Configure SSL for SAP NetWeaver Mobile 7.1 Applicable"
Check various forms, without finding a solution ...
some idea of the problem?
Thanks!!

Hi,
Follow the below given links to configure SSL
--> Making External Server Certificates Trusted
http://help.sap.com/saphelp_dm40/helpdata/en/0f/8d80f68eace441b3d1ebdc4b
2f2c81/content.htm (The link applies for PDA also)
--> Configure the below given parameters in the default.properties
com.sap.tc.mobile.sync.http.sslenabled
> Default value: True
com.sap.tc.mobile.sync.https.hostnameverifying
> Default value: True
com.sap.tc.mobile.sync.https.truststore
> Location of truststore file containing SSL certificates. If the
given location is not absolute, the system searches for the file in a
path that is relative to the installation directory.
For more details refer Note : 1312866
And follow the below given link :
http://help.sap.com/saphelp_nwmobile71/helpdata/en/06/a7d001e17b421db7e2
dd8279853971/frameset.htm
--> Even after following the above mentioned steps,Do the following :
Create the Trustsore on a PC and then use a Addon to
deploy these files to the PDA along with the SSL Libraries.
Regards,
Suma

Untrusted server cert chain - while connecting with ldap

Hi All,
I am getting the following error while running a standalone java program in windows 2000+jdk1.3 environment to connect with LDAP.
javax.naming.CommunicationException: hostname:636 [Root exception is ja
vax.net.ssl.SSLException: untrusted server cert chain]
javax.naming.CommunicationException: hostname:636. Root exception is j
avax.net.ssl.SSLException: untrusted server cert chain
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(DashoA12
275)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA12275)
at java.io.OutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Unknown Source)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at javax.naming.directory.InitialDirContext.<init>(Unknown Source)
at Test2.getProxyDirContext(Test2.java:66)
at Test2.main(Test2.java:40)
Any help would be appreciated
Thanks in Advance
Somu

This got resolved when in the code the following
System.setProperty("javax.net.ssl.tmrustStore", CertFileName);
where cert file name is the filename with complete path.the file is a CA certificate of the LDAP server
in X509 format

Ignoring untrusted server cert chain SSLException

Does anyone know how to get hold of the input stream of an https url that has an untrusted server cert chain?
I'm trying to read the contents of a page hosted on a machine with a self signed or expired certificate but HttpsURLConnection.getInputStream() will just throw an SSLException saying "untrusted server cert chain" rather than returning an input stream. Do you know how I might avoid the exception and get the stream?

Hi MPistoia
u have to import server cert inside a keystore and use it in your code.
I suggest you to download keyman tool from ibm (http://www.alphaworks.ibm.com/tech/keyman)..it's very simple and
it works great.
This are the steps
1. Navigate with netscape to that url
2. accept certificate
3. Launch keyman tool and import server certificate from netscape
4. save a file client.keystore and obviously remember your keystore password
5. use this code to connect
SSLSocketFactory ssf;
TrustManagerFactory tmf;
KeyStore ks;
FileInputStream fis;
String pathKeyStore="C:\\client.keystore";
char[] passphrase = "keystorePassword".toCharArray();
fis=new FileInputStream(pathKeyStore);
ks = KeyStore.getInstance("JKS");
ks.load(fis, passphrase);
tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tmf.getTrustManagers(), null);
fis.close();
try {
URL url = new URL("https://yourpage");
com.sun.net.ssl.HttpsURLConnection connection = (com.sun.net.ssl.HttpsURLConnection) url.openConnection();
ssf = ctx.getSocketFactory();
connection.setSSLSocketFactory(ssf);
connection.connect();
System.out.println("Ok :" + connection.getURL());
this code should work..
good luck
Michele

SSLException : untrusted server cert chain in java client, but not getting that with weblogic.

Hi,
I am bit confused about what i am seeing,
a. i used java client to talk to talk to server, got "untrusted server cert chain"
, ressolved the exceptio by adding certificate to cacerts file.
b. tried to connect to server using another weblogic server and not getting "untrusted
server cert chain", even when the certificates are not installed.
i dont know why it is throwning the SSLException in (a) and not in (b).
thanks,
Nirmala

Stand alone client takes its trusted certificate from the JDK cacerts keystore
by default.
SSL client running on server uses server trust configuration. By default the server
is configured to trust the CAs with certificates in DemoTrust.jks keystore and
the JDK cacerts keystore.
Pavel.
"Nirmala" <[email protected]> wrote:
>
Hi,
I am bit confused about what i am seeing,
a. i used java client to talk to talk to server, got "untrusted server
cert chain"
, ressolved the exceptio by adding certificate to cacerts file.
b. tried to connect to server using another weblogic server and not getting
"untrusted
server cert chain", even when the certificates are not installed.
i dont know why it is throwning the SSLException in (a) and not in (b).
thanks,
Nirmala

Untrusted server cert chain Error

I am trying to connect to a HTTPS server using a jsp page, running JRUN 1.3 and JSSE 1.0.2.
I have an error message consistenly that says: "untrusted server cert chain".
I believe that the certificate is ok, and JSSE is configured properly.
Here is the code I am using, do you know where the preoblem is?
<html>
<%@ page import="java.io.*"%>
<%@ page import="java.net.*"%>
<%@ page import="com.sun.net.ssl.*"%>
<%@ page import="java.security.*"%>
<%@ page import="java.util.*"%>
<head>
     <title></title>
</head>
<body>
<%
System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("javax.net.debug", "help all");
URL thisURL=new URL("https://test.com/index.html");
URLConnection uCon= null;
uCon = (URLConnection) thisURL.openConnection();
InputStreamReader isr=new InputStreamReader(uCon.getInputStream());
BufferedReader brObject=new BufferedReader(isr);
//printing out
String line = "";
StringBuffer sb     =     new StringBuffer();
while ((line = brObject.readLine()) != null){
          sb.append(line);
sb.toString();
%>
</body>
</html>

Why dont u try to connect to
https://www.verisign.com
Code seems to be correct. If it doesnt work, mail me at
[email protected]

Untrusted server cert chain

Our product is a server. It uses Tomcat to receive HTTP requests.
We would like tomcat to serve HTTP/SSL (https) directly.
As described in the Tomcat documentation, we have used the Sun keytool.exe to create the SSL certificate.
This certificate is autosigned.
Tomcat is now running and supports SSL on port 8443.
One client of our server try to send an HTTP request to our server.
Here is the code of the client program:
     // Declaring SSL Provider
     com.sun.net.ssl.internal.ssl.Provider provider = new com.sun.net.ssl.internal.ssl.Provider ();
     Security.addProvider(provider);
     // Opening connection
     URL processUrl = new URL("https://serverHostName:8443/serverApp/serverJSP.jsp");
     m_httpsCnct = (HttpsURLConnection)processUrl.openConnection();
     // Connection settings
     // Posting request
     OutputStreamWriter osw = new OutputStreamWriter(m_httpsCnct.getOutputStream());
At this point, the following exception and debug info is thrown :
     %% No cached client session
     *** ClientHello, v3.1
     Thread-0, WRITE: SSL v3.1 Handshake, length = 59
     Thread-0, WRITE: SSL v2, contentType = 22, translated length = 16310
     Thread-0, READ: SSL v3.1 Handshake, length = 664
     *** ServerHello, v3.1
     %% Created: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
     ** SSL_RSA_WITH_RC4_128_SHA
     *** Certificate chain
     Thread-0, SEND SSL v3.1 ALERT: fatal, description = certificate_unknown
     Thread-0, WRITE: SSL v3.1 Alert, length = 2
     javax.net.ssl.SSLException: untrusted server cert chain
          at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.ClientHandshaker.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.Handshaker.process_record([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.ssl.AppOutputStream.write([DashoPro-V1.2-120198])
          at java.io.OutputStream.write(Unknown Source)
          at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
          at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.getOutputStream([DashoPro-V1.2-120198])
I believe that my certificate is not trusted because it is autosigned.
Is it true?
Can I customize my client to accept this certificate?
We register dynamically the SunJSSE Provider. It seems to take a long time. How can we avoid this?
We didn't complete successfully the static registration.
Any help would be appreciated.
Thanks.

I believe that the server is not trusted because it is not in your so-called "truststore." If you import the server certificate into a keystore using keytool and then reference that keystore as your "truststore", then you should be able to authenticate the server.
One approach is to hit the server via a browser, save the server certificate, and export it. Then import it via keytool. You should be able to configure properties (jdk1.4 example below) such as:
javax.net.ssl.trustStore=<path-to-truststore>
javax.net.ssl.trustStoreType=JKS
javax.net.ssl.trustStorePassword=<password>
Good luck!

Untrusted server cert chain & does not recognize the certificate authority

I have java code that makes an ssl connection to an HTTPS server.
The code workes fine when I connect to a server that has a
certificate that was issued by a recognizable authority.
But when I try to connect to our test HTTPS server which has a
certificate that was created by ourselves for debug, I get this
java exception: "untrusted server cert chain".
When I connect to our test HTTPS server with a browser, I get
this message from the browser in a popup window:
"www.xyz.com is a web site that uses a security certifcate to
identify itself. However netscape 6 does not recognize the
certificate authority that issued this certificate."
At this point I am able to accept the certificate in the popup
window and continue.
Question: In my java code how can I accept a certificate
that was signed by an unrecognizable authority just like the
browser can. Or during debug, how can I set an override
to accept ALL certs no matter what.
Thanks.....Paul

You will have to import your server test certificate into your client machine keystore. By default the keystore will be the 'cacerts' file in JAVA_HOME/jre/lib/security, get your server certificate in .pem format and use keytool to import it to the client.
keytool -import -alias <anything> -file <full path of .pem file> -keystore <full path of cacerts file>
The keystore password is 'changeit' by default, keytool comes with the JDK.
The reasoning behind this is to prevent the misuse of test certificates, the client has to consciously import an untrusted certificate. When you install a real certificate on your server the client will be automatically validated if bought from a trusted CA (Thawte, Verisign).
Take a look at the java.security.KeyStore class, you can use it to view your certificate chain.
Ronny.

Punchout problem. CertificateException: Untrusted Cert Chain.

Similar Messages

Maybe you are looking for