HTTPS certificate chain incomplete

[Former Member]

Hello,

we are getting the infamous certificate chain error when making an HTTPS call from an RFC destination type G:

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

ERROR in af_verify_Certificates: (27/0x001b) Chain of certificates is incomplete : "CN=210.60.170.10, OU=XYZ, O=XYZ, C=DE"

ERROR in get_path: (27/0x001b) Found root certificate of <CN=210.60.170.10, OU=XYZ, O=XYZ, C=DE> which does not fit the give

ERROR in verify_with_PKs: (27/0x001b) Found root certificate of <CN=210.60.170.10, OU=XYZ, O=XYZ, C=DE> which does not fit the given PKRoot

(CN-IP and OU,O changed manually here in the thread for security reasons)

I know that we have to make the server certificate known to STRUST. Problems with this certificate:

- it contains an IP adress, not a hostname

- it is a self-signed certificate, without trusted Root CA

The provider does not have a full valid certificate with Root CA (strange, but that is the fact).

Question: does anybody know if we can make XI work with such a certificate ? Could we issue a certificate request to a CA authority and then add the response to STRUST ? But even with that, when we make the HTTPS call and receive the server cert, we will receive a server cert without valid root CA ! Can we configure in XI STRUST to accept this cert also as root CA ?? I tried many things, e.g. added the cert to the SSL Server PSE, but nothing helped (always restarted ICM)

Or can we configure XI to bypass that server cert check ? I think the Business Connector does that, because we are moving from BC to XI, and on BC it works fine without the server cert.

CSY

[Former Member]

Closed question. Solved by OSS-call.

The following is no problem:

- it contains an IP adress, not a hostname

- it is a self-signed certificate, without trusted Root CA

STRUST was wrongly configured.

CSY

[Former Member]

Hi,

I am facing the similar error, can you please let me know what was wrongly configured on yur server ?

Your help in this regard will be highly appreciatied.

Thanks

Narender

[madanmohan_agrawal]

Hi Christian,

Are you using the host name in "Target Host" field in your RFC Destination type G.

If not then please use host name instead of IP address and then try.

regards,

Madan Agrawal

[Former Member]

Have you gone through SAP Note 510007?

[Former Member]

yes, we have gone through this note. The basic requirements (SAP CryptoLib) are fullfilled, we have productive other HTTPS connection, which are working fine. Those partners provide us a valid certificate with trusted root CA.

About the hostname, the provider only gave us a fix IP adress. We have no hostname. I assume that the target host value is important when XI tries to match that value with the server certificate's CN value (?). And because the certificate contains an IP (not hostname), that should be fine (?)

Edited by: Christian Sy on Apr 16, 2009 6:34 AM

[madanmohan_agrawal]

Christian Says..
the certificate contains an IP (not hostname), that should be fine (?)

The SSL handshake needs to confirm that the HTTPS client is using the HTTPS server's DNS name to access the HTTP service since only the DNS name of the HTTPS server is stored in the certificate signed by the trusted CA (e.g. VeriSign). That does make sense since it's the way the Certification Authorities works.

Regards,

Madan Agrawal