The verification of the server's certificate chain failed

[former_member204618]

Hi All,

Not sure this is the right forum for this but never mind.

I am trying to get abap2GApps working and am having problems with the client certificates.

I am getting the below error in ICM :-

[Thr 06] Mon Jul 30 09:34:47 2012

[Thr 06] *** ERROR during SecudeSSL_SessionStart() from SSL_connect()==SSL_ERROR_SSL

[Thr 06]    session uses PSE file "/usr/sap/BWD/DVEBMGS58/sec/SAPSSLC.pse"

[Thr 06] SecudeSSL_SessionStart: SSL_connect() failed

  secude_error 9 (0x00000009) = "the verification of the server's certificate chain failed"

[Thr 06] >>            Begin of Secude-SSL Errorstack            >>

[Thr 06] ERROR in ssl3_get_server_certificate: (9/0x0009) the verification of the server's certificate chain failed

ERROR in af_verify_Certificates: (24/0x0018) Chain of certificates is incomplete : "OU=Equifax Secure Certificate Authority, O=E

ERROR in get_path: (24/0x0018) Can't get path because the chain of certificates is incomplete

[Thr 06] <<            End of Secude-SSL Errorstack

[Thr 06]   SSL_get_state() returned 0x00002131 "SSLv3 read server certificate B"

[Thr 06]   SSL NI-sock: local=172.30.7.170:59036  peer=172.30.8.100:80

[Thr 06] <<- ERROR: SapSSLSessionStart(sssl_hdl=60000000053910f0)==SSSLERR_SSL_CONNECT

[Thr 06] *** ERROR => IcmConnInitClientSSL: SapSSLSessionStart failed (-57): SSSLERR_SSL_CONNECT {000726d5} [icxxconn_mt.c 2031]

Having already got the accounts.google.com SSL certificate chain installed and working I can't get the docs.google.com SSL chain working.

For accounts.google.com they use (this set works) :-

1) CN=accounts.google.com, O=Google Inc, L=Mountain View, SP=California, C=US

2) CN=Thawte SGC CA, O=Thawte Consulting (Pty) Ltd., C=ZA

3) OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

For docs.google.com they use a different set of SSL certs. :-

1) CN=*.google.com, O=Google Inc, L=Mountain View, SP=California, C=US

2) CN=Google Internet Authority, O=Google Inc, C=US

3) OU=Equifax Secure Certificate Authority, O=Equifax, C=US

Can anyone explain what I am doing wrong or how to correct this?

Thanks

Craig

[former_member204618]

Can no one help?

Cheers

Craig

[former_member186752]

Hi Craig

Did you find a solution?

Cheers

Marian

[former_member128291]

Dear Craig,

This error seems to be during ssl handshake. The relevant certificate is unknown, and the chain of certificates is incomplete. This issue is described in SAP notes 1094342 and 1318906.

Please try to follow these notes to add the missing certificate into the certificate list of the PSE these RFC uses. Kindly try to use transaction STRUST as per the notes. And after that, also try to restart the

ICM and test again.

Best Regards,

Abhishek

[former_member204618]

Abhishek,

Not to point out the obvious here but I have done this already.

All 3 certificates related to docs.google.com

For docs.google.com they use a different set of SSL certs. :-

1) CN=*.google.com, O=Google Inc, L=Mountain View, SP=California, C=US

2) CN=Google Internet Authority, O=Google Inc, C=US

3) OU=Equifax Secure Certificate Authority, O=Equifax, C=US

Have been installed downloaded from a browser but this doesn't help.  I even as mentioned installed the Root CA certificate directly from GeoTrust and this doesn't help either.

Even without any certificates installed I get the same error!

We are using the latest version of SSF

SSFLIB Version 1.555.34 ; SAPCRYPTOLIB Version

5.5.5pl34 (+MT) #Copyright (c) SAP AG, 2011

We are running BI7 EHP1 SP07.

Cheers

Craig

[former_member204618]

OK resolved this problem, someone had installed the accounts.google.com cert within other sections.  Once I removed this and had just the root certs in the SSL Client SSL Client (Anonymous) PSE the error disappeared but was replaced by another!

[Thr 05] <<- SapSSLSetTargetHostname(sssl_hdl=60000000052e0030)==SAP_O_K
[Thr 05]      in: hostname = "www.googleapis.com"
[Thr 05]   MatchTargetName("www.googleapis.com", CN="accounts.google.com") MISmatch
[Thr 05] <<- ERROR: SapSSLSessionStart(sssl_hdl=60000000052e0030)==SSSLERR_SERVER_CERT_MISMATCH
[Thr 05]          status = "resumed SSL session"
[Thr 05]       Server DN = "CN=accounts.google.com, O=Google Inc, L=Mountain View, SP=California, C=US"
[Thr 05] <<- SapSSLErrorName()==SSSLERR_SERVER_CERT_MISMATCH
[Thr 05] *** ERROR => IcmConnInitClientSSL: SapSSLSessionStart failed (-30): SSSLERR_SERVER_CERT_MISMATCH {000500fb} [icxxconn_m

Now the problem here is I need both certificates because I must first call accounts.google.com to authenticate and retrieve an authentication token then run a query against www.googleapis.com.  How is this to work?  What's causing it to reuse essentially the other SSL session even though I close the client connection with CALL METHOD client->close after the first call?

I also get the same problem using SM59 with 2 connections using the 2 different URLs.

Here is what is currently set up in strust on my system :-

Simply the 2 root certs required by both accounts.google.com and by www.googleapis.com in that order, although I still experience the same issue without the first cert!

Please help as this is driving me insane.

Thanks

Craig

[former_member204618]

OK problem solved but not ideal.

I had to import the root certificate for one domain into the Standard Client PSE and keep the other one in the anonymous PSE.

Surely this isn't how it's supposed to work.  What happens if I have 2 different domains which each use the same wildcard certificate and so the same root certificate.  Then I have got the same problem.

Any suggestions?

Cheers

Craig

[Former Member]

Hi I am havin gthe same issue.. I was given a pfx fiel and a root certicate and i have created an httpsssl.pse connection. I have loaded the pse and also the roor certificate but i get this error..

[Thr 13] ->> SapSSLErrorName(rc=-30)

[Thr 13] <<- SapSSLErrorName()==SSSLERR_SERVER_CERT_MISMATCH

[Thr 13] *** ERROR => IcmConnInitClientSSL: SapSSLSessionStart failed (-30): SSSLERR_SERVER_CERT_MISMATCH {00020013} [icxxconn_mt.c

[Thr 13] ->> SapSSLSessionDone(&sssl_hdl=100ec48f0)

[Thr 13] <<- SapSSLSessionDone()==SAP_O_K

[Thr 13]      in: sssl_hdl   = 107217b30

[Thr 13]          ... ni_hdl = 201

[Thr 13] IcmConnConnect(id=2/19): free MPI request blocks

[Thr 13] MPI<41efb>f#7 GetInbuf -1 2e6ad0 229 (1) -> MPI_EOS: End Of Stream

CaN someone please help.. I am stuck ..

I was given this to test from the bussiens

https://dm1.amos.fly.com:443/service/i_sap_userinfo .. but when i try to brign this up in ie it fails..

[former_member317844]

Your root cert in NOT trusted

This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store.

You can import the root cert. to you browsres "trusted Publicers"

Thi sshould fix you problem

[former_member204618]

Further UPDATE

After removing every certificate related to docs.google.com I still get the same error!

I have even tried downloading the root certificate directly from GeoTrust themselves and yet I still get the same error.

I have even resorted to running SAP program ZSSF_TEST_PSE from note 800240 to check the PSE and all is well!

Referring to SAP Note 1318906 suggests I am missing a certificate in the chain but I am not!

"Situation: The ICM is in the client role and the following entry is displayed in the trace:

ERROR in ssl3_get_server_certificate: (9/0x0009) the verification of the server's certificate chain failed

Reason:You try to set up a secure connection to a server, but the validity of the certificate cannot be verified because the required certificates are not available.

Solution:The missing certificates are listed in the trace file. You must use transaction STRUST to insert these certificates in the Personal Security Environment (PSE) that is used for the connection. The certificates are usually made available to you by the server administrator. If the certificates are public Certification Authority (CA) certificates, you can also request the certificates there."

What could possibly causing this?

Please help!

Craig