With all the SSL fun on the other thread, recently ran into our own problem.

We have IS 6.0.1 SP3 and are trying to connect to a remote partner using SSL using pub.client:http. What we see is that our IS rejects the cert chain presented by the remote site because it isn’t a valid chain. Various permutations of the trustedCA’s directory haven’t yielded success.

Other tools including IE, Vordel’s SOAPBox, and OpenSSL are able to connect fine. After a little digging, we discovered the following with OpenSSL: the remote site was presenting it’s 3-cert-chain out of order. Instead of
publicCert
intermediateCACert
rootCACert

we see
publicCert
rootCACert
intermediateCACert

And we believe this would explain why it’s failing validation in IS. Has anyone else encountered this or found a workaround? Given that IS is obviously in the minority by rejecting the cert, we’d like to try and handle it on our side.

Thanks,
Tate

Thanks to webM support on this one. Not a fix, but an explanation of the TLS spec. SSL is slightly less specific, but still requires the root CA come last:

"We found a similar issue about this topic. Please check the page RFC ([url=“http://www.ietf.org/rfc/rfc2246.txt”]http://www.ietf.org/rfc/rfc2246.txt[/url]), see page 38:

===============
certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender’s
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
==============="

Tate,

Thanks for sharing the solution you found. Certs are black magic as far as I’m concerned.

Mark

Mark,
We ran into the EXACT same problem trying to integrate with a partner.
I have two solutions for you.

1. When we thought our partner will be reluctant to fix the certificate chain order on their side, we overwrote the chainverifier class.

2. The partner fixed the certificate chain on their side. Apparently this problem of wrong order in the cert chain happens if they use Microsoft stuff on their side.

To figure out this problem we used the OpenSLL client command that lists the certificats in order and sent them the dump. They made fixes on their side. Call me/e-mail me if you want me to send you the java code fix.

Prasad