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)
- Partner Cert (12 69 0a 8d d8 92 55 a3 16 7a d3 6a b9 f9 d3 69)
- VeriSign Class 3 Extended Validation SSL SGC CA (2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 43)
- 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)
-
Partner Cert (12 69 0a 8d d8 92 55 a3 16 7a d3 6a b9 f9 d3 69)
-
Class 3 Public Primary Certification Authority (57 bf fb 03 fb 2c 46 d4 e1 9e ce e0 d7 43 7f 13)
-
VeriSign Class 3 Extended Validation SSL SGC CA (2c 48 dd 93 0d f5 59 8e f9 3c 99 54 7a 60 ed 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]
today.
