certificate rejected by ChainVerifier

Hi

I have some problem connecting to a server (https, using pub.client:http), I keep getting the following error: java.io.IOException: iaik.security.ssl.SSLException: Server certificate rejected by ChainVerifier

Using a packet sniffer I’ve verififyed that all the certificates received from the server exists in my trustedCAs folder.

The certificate chain looks like this:
[Root Cert] -Serial# 18 da d1 9e 26 7d e8 bb 4a 21 58 cd cc 6b 3b 4a
[Intermediate Cert] -Serial# 2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 43
[Signed Partner Cert]

The root cert and the intermediate cert are issued by verisign.
All the certificates in the chain have been extracted from the public key cert as DER-encoded X-509 files and placed under my trustedCAs folder as *.cer files.

I have the following extended settings:
watt.security.ssl.client.ignoreEmptyAuthoritiesList=true
watt.security.ssl.ignoreExpiredChains=true
watt.security.ssl.cacheClientSessions=false

It used to work perfectly, but after the server issued a new certificate (due to the old one expired) it seems like the IS somehow have a reference to the old certificate (even though its deleted from the trustedCAs folder).

I´ve even tried to remove the “Trusted CAs” folder since the IS by default should accept all server certificates, but it does not work.

I´m using IS 6.5 (394) on a fully patched windows xp professional.
Updates:
IS_6-5_SP3_Core_Fix1
IS_6-5_SP3_SrvPrtcl_Fix1
IS_6-5_SP3_WebSvcsXML_Fix1
IS_6-5_SP3
WmPRT_6-5-1_SP1

Does anyone know what might be wrong?
Any help is appreciated

Best Regards
Mikael

did you try refreshing the trusted CA certificates cache?

Cheers!
Prithvi

Hi

Yes, I’ve even restarted the IS, but not luck.
There is a support request on this matter on webmethods support center, but it seem to be quite a mystery for them too.

But hopefully they will solve it (i.e. explain to me what I did wrong :wink: today.

Regards
Mikael

Hi

This is the information the webmethods support has given me so far.
[FONT=Arial]Anyone on this forum that have any more ideas?

Regards[/font]
Mikael

[FONT=Arial][WM Reply 1]
Thank you for your support request. We are tracking this as SR 1-107653601.

Do you have any news since our phone call? From the way you presented the problem to me it seems that the old certificate has been stored in some cache somewhere, but that sounds pretty strange to me. If using the certificate with a browser you can perform the https call, that means that the certificate works fine, therefore the cache seems to the only solution left ….

In some documentation I found:
The sequence of certificates must be correctly ordered to be considered valid. Always: server certificate → intermediate certificate(s) → root certificate. If the chain is not in this order, then the IS will throw: ‘Server certificate rejected by ChainVerifier’.

And always about the same error:

This is an error thrown by the 3rd party security toolkit used by Integration Server. This error indicates that your server was acting as an SSL client, and during a handshake with an SSL server, was presented with a certificate chain which is not trusted by your configuration. This error is almost always caused by a misconfiguration on either the SSL client or SSL server side.

This error message may occur for any of the following reasons:

  • SSL Server Certificate Chain is Out of Order
    To determine if this is the root-cause, you must test if server certificate chain is out of order

  • SSL Server Certificate Chain Contains an Expired Certificate
    To determine if this is the root-cause, you must Test If SSL Server Certificate Contains Expired Certificate

  • Root CA Not Added to SSL Clients Trusted Key Store

Do you think one of these could fit your case?

[/font]

[FONT=Arial][My Reply 1]
I’ve summarized all the information for you below, don’t hesitate to ask if something seem to be a bit fuzzy or if you need some more information.
The hex codes next to every certificate is the unique serial number.

I’ve also attached all the certificates (after all, they are all public key certificates) in our trusted CAs folder.
nordnet.cer certificate is our 3rd partner public key certificate, which our IS does not seem to trust.

Public key certificate chain (downloaded from server (nordnet.cer), same as displayed in the browser when browsing to the site)

  1. Partner Cert (12 69 0a 8d d8 92 55 a3 16 7a d3 6a b9 f9 d3 69)
  2. VeriSign Class 3 Extended Validation SSL SGC CA (2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 43)
  3. Verisign (18 da d1 9e 26 7d e8 bb 4a 21 58 cd cc 6b 3b 4a)

Certificate chain received during SSL handshake
(The chain is the order of which is was displayed by Ethereal/Wireshark)

  1. Partner Cert (12 69 0a 8d d8 92 55 a3 16 7a d3 6a b9 f9 d3 69)

  2. Class 3 Public Primary Certification Authority (57 bf fb 03 fb 2c 46 d4 e1 9e ce e0 d7 43 7f 13)

  3. VeriSign Class 3 Extended Validation SSL SGC CA (2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 4)

  4. The intermediate certificate received during the handshake is not included in the certificate chain downloaded from the server.
    However, that particular certificate exist in the trusted CA’s folder.
    Due to the above, the certificate chains are not identical - could this be the reason?

To answer you questions / ideas:

  • SSL Server Certificate Chain is Out of Order
    All the certificates in the chain are up to date.
    How can I verify the chain is not out of order?

  • SSL Server Certificate Chain Contains an Expired Certificate
    All the certificates in the chain are up to date.

  • Root CA Not Added to SSL Clients Trusted Key Store
    I’m not sure where to find the SSL Clients Trusted Key Store - or is it the same as the “trusted CA’s” folder?

Is the above information enough to pinpoint the problem, or do you need to anything more?

[WM Reply 2]
To be honest, I never faced an issue like this one and I do not know exactly how the order of the certificates should be. I think you should use the fact that setting the certificates in your browser everything is working fine. Maybe you could try and perform the call with the browser and monitor the order of the certificates with ethereal. Then you could take this order as a model for the order of the chain to be set in the IS.

[My Reply 2]
I haven’t found anything more - so we still have a problem regarding the certificate’s.

You mention there is a way to set the order of the chain in the IS - how can I do that?

The second question is, why has the following settings no effect?
watt.security.ssl.ignoreExpiredChains=true
watt.security.ssl.cacheClientSessions=false

watt.security.cert.wmChainVerifier.trustByDefault=true

If watt.security.cert.wmChainVerifier.trustByDefault=true, the IS should trust all certificates no matter what.
Could this be a problem with the IS?

We continue to work on this matter to try and find a solution.
[/FONT]

With the OpenSSL toolkit and a bit of work, you should be able to verify independently whether your cert chain is valid. Also try opening the cert from Windows file manager and clicking on view details. That (sometimes) will show if there is an issue with a particular cert.

Mark

Hi

I’ve tried to to verify the public key certificate using openSSL and I do get some issuer warnings/errors, but with an OK at the end.

openssl verify -CAfile ca_list.crt -purpose sslserver -issuer_checks -verbose nordnet.crt

(‘nordnet.crt’ is the public key certificate received from our partner)

The output is:
nordnet.crt:
/serialNumber=5164060021/1.3.6.1.4.1.311.60.2.1.3=SE/C=SE/2.5.4.17=SE-167 14/ST=Bromma/L=Stockholm/2.5.4.9=Gustavslundsvagen 139/O=Nordnet Ban
k AB/OU=Terms of use at
www.verisign.com/rpa (c)06/CN=www.nordnet.se
error 29 at 0 depth lookup:subject issuer mismatch

/serialNumber=5164060021/1.3.6.1.4.1.311.60.2.1.3=SE/C=SE/2.5.4.17=SE-167 14/ST=Bromma/L=Stockholm/2.5.4.9=Gustavslundsvagen 139/O=Nordnet Bank AB/OU=Terms
of use at
www.verisign.com/rpa (c)06/CN=www.nordnet.se
error 29 at 0 depth lookup:subject issuer mismatch

/serialNumber=5164060021/1.3.6.1.4.1.311.60.2.1.3=SE/C=SE/2.5.4.17=SE-167 14/ST=Bromma/L=Stockholm/2.5.4.9=Gustavslundsvagen 139/O=Nordnet Bank AB/OU=Terms
of use at
www.verisign.com/rpa (c)06/CN=www.nordnet.se
error 29 at 0 depth lookup:subject issuer mismatch

/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
error 29 at 0 depth lookup:subject issuer mismatch

OK

The errors above seem to be missleading - the issuer of the ‘nordnet’ certificate is included in the ‘ca_list.crt’ file.

Some additional output from the IS:
ssl_debug(1): Starting handshake (iSaSiLk 3.03)…
ssl_debug(1): Sending v2 client_hello message, requesting version 3.1…
ssl_debug(1): Received v3 server_hello handshake message.
ssl_debug(1): Server selected SSL version 3.1.
ssl_debug(1): Server created new session BA:4B:5C:A8:2E:9D:E8:E1…
ssl_debug(1): CipherSuite selected by server: SSL_RSA_WITH_RC4_128_MD5
ssl_debug(1): CompressionMethod selected by server: NULL
ssl_debug(1): Received certificate handshake message with server certificate.
ssl_debug(1): Server sent a 1024 bit RSA certificate, chain has 3 elements.
com.wm.util.LocalizedCertificateException: [ISC.0009.9001] Certificate chain bro
ken: not linked properly

ssl_debug(1): Sending alert: Alert Fatal: bad certificate
ssl_debug(1): Shutting down SSL layer…
ssl_debug(1): SSLException while handshaking: Server certificate rejected by Cha
inVerifier

Regards
Mikael

Hey

I´d just like to inform u all how we solved this issue, so even I have contributed with something :slight_smile:

The reason for our problem was that the server side was sending the certificates (during the handshake) in the wrong order (compared to the chain), which made the IS reject the chain.

What our partner (who was acting server) did was switching place of 2 certificates in an intermediate certificate file (bundle file, contained 2 certificates). This small modification made the server send the whole chain in the proper order, and hence the IS now also trusts the certificate chain :smiley:

Thank you all for good ideas, tips & trix

Kind regards,
Mikael