PI cannot handle irrelevant certificate in chain

[Former Member]

Hi.

I have a problem establishing SSL communication with a 3rd party webservice from PI. The certificate chain contains 4 certificates, but two of them is on the same "level", and this seems to be a problem for PI:

- *.<3rd_party_domain>.com (signed by GlobalSign Organization Validation CA - G2)

- GlobalSign Domain Validation CA - G2 (signed by GlobalSign Root CA)

- GlobalSign Organization Validation CA - G2 (signed by GlobalSign Root CA)

- GlobalSign Root CA

When I open the certificate in Windows IE, only three certificate are shown. The Domain certificate is neglected.

I tried to fire on the webservice from a Windows client (soapUI), and it shows 3 certificates (the top three - Root certificate is not shown).

In XPI Inspector I get the following.

What can I do to make PI accept the irrelevant Domain certificate?

Regards

Rasmus

---

Found Certificate chain with 3 elements:

Certificate #0

    SubjectDN: CN=*.<3rd_party_doman>.com,O=...<snip>..

    IssuerDN: CN=GlobalSign

Organization Validation CA - G2,O=GlobalSign nv-sa,C=BE

Certificate #1

    SubjectDN: CN=GlobalSign Domain Validation CA - G2,O=GlobalSign

nv-sa,C=BE

    IssuerDN: CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign

nv-sa,C=BE

Certificate #2

    SubjectDN: CN=GlobalSign Organization Validation CA -

G2,O=GlobalSign nv-sa,C=BE

    IssuerDN: CN=GlobalSign Root CA,OU=Root

CA,O=GlobalSign nv-sa,C=BE

Begin Analyzing Certificate Chain:

    The certificate #0 was signed by the certificate #2

    The certificate with DN = {CN=GlobalSign Domain Validation CA - G2,O=GlobalSign nv-sa,C=BE} appears to be signed by {CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE}, however, the signing certificate was not provided in the chain.

    The certificate with DN = {CN=GlobalSign Organization Validation CA - G2,O=GlobalSign nv-sa,C=BE} appears to be signed by {CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE}, however, the signing certificate was not provided in the chain.

End Analyzing Certificate Chain.

Begin IAIK

Debug:

ssl_debug(59): Starting handshake (iSaSiLk 4.1)...

ssl_debug(59): Sending v3 client_hello message, requesting version 3.2...

ssl_debug(59): Received v3 server_hello handshake message.

ssl_debug(59): Server selected SSL version 3.1.

ssl_debug(59): Server created new session 9B:AD:96:18:3F:47:B2:E4...

ssl_debug(59): CipherSuite selected by server: SSL_RSA_WITH_3DES_EDE_CBC_SHA

ssl_debug(59): CompressionMethod selected by server: NULL

ssl_debug(59): Received certificate handshake message with server certificate.

ssl_debug(59): Server sent a 2048 bit RSA certificate, chain has 3 elements.

ssl_debug(59): ChainVerifier: Found a trusted certificate, returning true

ssl_debug(59): Received server_hello_done handshake message.

ssl_debug(59): Sending client_key_exchange handshake message (2048 bit)...

ssl_debug(59): Sending change_cipher_spec message...

ssl_debug(59): Sending finished message...

ssl_debug(59): Received change_cipher_spec message.

ssl_debug(59): Received finished message.

ssl_debug(59): Session added to session cache.

ssl_debug(59): Handshake completed, statistics:

ssl_debug(59): Read 3827 bytes in 5 records, wrote 426 bytes in 4 records.

ssl_debug(59): Shutting down SSL layer...

ssl_debug(59): Sending alert: Alert Warning: close notify

ssl_debug(59): Read 0 bytes in 0 records, 0 bytes net, 0 average.

ssl_debug(59): Wrote 0 bytes in 0 records, 0 bytes net, 0 average.

ssl_debug(59): Closing transport...

ssl_debug(59): Closing transport...

End

IAIK Debug.

     ERROR: The issuer of the certificate #0 doesn't match the subject of certificate #1

     ERROR: The issuer of the certificate #1 doesn't match the subject of certificate #2

[Former Member · Accepted solution]

Hello Rasmus,

My name is Rick and I work for GlobalSigns Support team and I'm hoping to resolve your problem.
The errors you mentioned make sense as one of the certificates you are using is not relevant for your use, which is the Domain Validation Certificate

The certificates need to match up in a chain so that it would be displayed as follows;

Your Web Certificate    *.<3rd_party_doman>.com

            I

Intermediate Certificate  GlobalSign Organization Validation CA - G2

            I

  Root Certificate          GlobalSign Root CA                     

So if you remove the Domain Validated Intermediate then you should be able to use it.

Looking forward to your response.

Regards,
Rick

GlobalSign Support Team

[Former Member · Accepted solution]

Hi Rick.

Yes, I am aware that the chain contains an irrelevant certificate. The chain however is supplied by the 3rd party webservice I am trying to communicate with, and I have no saying in the matter of removing the certificate from the chain. It is not my certificate as indicated on your "graphic".

The chain is delivered to me when calling the webservice. The 3rd party is also aware of the problem, but arguments that even though the chain contains the extra certificate, the chain is in fact valid, and that they got the certificate from GlobalSign. They are not willing the change their certificate.

Internally we are now trying to migrate the configuration scenario to another PI system with newer SSL drivers to see, if this could solve the problem.

Regards,

Rasmus

[Former Member · Accepted solution]

Hi Rick.

I would like to hear from you (working for GlobalSign) if the certificate in question is in fact valid. It seems that both Internet Explorer and soapUI can handle the extra certificate, but PI cannot. Is it PI that does not process the SSL layer correctly, or is it the certificate that is invalid? The certificate is issued from GlobalSign.

Regards,

Rasmus

[Former Member · Accepted solution]

Hi Rasmus,

It would be difficult to say without running the relevant checks and having the domain name. But you could use tools like https://www.ssllabs.com/ssltest/ or http://certlogik.com/ssl-checker/

Generally browsers handle certificates completely different than client side programs because browser will attempt to use the required certificates locally first. If the certificates in question are not available locally then it will request the server for the complete certificate chain and can cause a problem with a certificate installed like your original example.

I will be honest in saying that I am not familiar with PI but I presume it does not have a local certificate store so it will grab it from the server so unless the incorrect certificate can be ignored or accepted it will continue being a problem.

The SSLLabs will most likely throw an error with that 3rd party certificate with the chain so it may be worth passing that information onto them, it may just get them to remove it.

Kind Regards,
Rick

[Former Member · Accepted solution]

Hi again.

The 3rd party site is only accessible when caller is in a white-list, and therefore the two tools you mentioned cannot connect and check the certificate chain. This is up-hill 😞

PI does have a keystore, and we have tried combinations of the four certificates in question. We have tried to delete all certificates in the keystore, to include all in the keystore and every combination in between. Nothing does the trick.

Regards,

Rasmus

[Former Member · Accepted solution]

And now for the grand finale...

The 3rd party has now testet the GlobalSign certificate chain (presumably) using the online tools mentioned earlier, and the "ghost" certificate has now been removed form the chain. PI is now happy - at least for that part, and the chain validates. Now I can get to the signing and validation of the XML part.

Thanks for the help.

Rasmus

[Former Member · Accepted solution]

Hi Rasmus,

Great to hear you got it sorted and that they removed the irrelevant intermediate.
Have a great week and thank you for the update.

Kind Regards,

Rick Kramer