SSL handshake failure reported on starting ELM 7.0
<Environment>
We are testing the new ELM 7.0 with the bundled Liberty server and on starting the server it reports a nasty-looking SSL handshake error in the messages.log. Others setting up ELM 7.0 are reporting the same. The server seems to start up and appears to be working OK. We are just using as is the ibm-team-ssl.p12. Is this a known issue?
[20/05/11 14:46:35:192 JST] 000000ce com.ibm.ws.ssl.core.WSX509TrustManager E CWPKI0823E: SSL ハンドシェークの失敗: SubjectDN [CN=www.ibm.com, O=IBM, L=Armonk, ST=New York, C=US] の署名者がホスト [www.ibm.com:443] から送信されました。SSL 構成別名 [defaultSSLConfig] にあるトラストストア [C:/Program Files/IBM/JazzTeamServer/server/liberty/servers/clm/resources/security/ibm-team-ssl.p12] にこの署名者を追加する必要がある可能性があります。SSL ハンドシェーク例外からの拡張エラー・メッセージ: [PKIXCertPathBuilderImpl could not build a valid CertPath.] [20/05/11 14:46:35:192 JST] 000000ce SystemErr R javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: PKIXCertPathBuilderImpl could not build a valid CertPath. |
Accepted answer
I had same with 6061. The JTS tries to connect to ibm.com at least during startup. I think this is for the name resolution test, for which you can configure the URL in advanced properties of JTS.
The error is just not nice in the log, but not severe.
The issue is, the cert of IBM.com is signed by DigiCert Global Root CA and by GeoTrust RSA CA 2018. This can be seen, if you just open ibm.com in the browser and check the certificate chain.
Both certs must be in the trust store, which you reference in the server.xml default ssl section.
The DigiCert Global Root CA is in the Java cacerts of the IBM JRE included, but the GeoTrust RSA CA 2018 not. SO if you are using the standard cacerts from the Java, you have to add the GeoTrust to the store.
Btw. cacerts is jks format. But you can also use p12 if you convert jks to p12.
regards
Guido
Ian Wark selected this answer as the correct answer
Comments I have gone to ibm.com in a browser by clicking the padlock and found GeoTrust RSA CA 2018 andDigiCert Global Root CA. I scrolled down the page to the PEM (cert) / PEM (chain) download section and downloaded the PEM (cert). I then checked in the ELM jre cacert using below:
And it is there. And as you say Geotrust is not there.
So I imported like this:
keytool -alias mykey -import -trustcacerts -file C:\www-ibm-com.pem -keystore "C:\Program Files\IBM\JazzTeamServer\server\jre\lib\security"\cacerts
I can see that it has imported. I restarted Liberty server.. but it has not removed the error in messages.log yet.
I haven't created any new self-signed certificate, so it is still using the ibm-team-ssl.p12 with the default self-signed certificate using "localhost".
Is there something else I need to do?
Actually, this didn't resolve the issue. The call to ibm.com comes from the clmhelp. https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=505608
Long term fix from 19.0.0.12 is trustDefaultCerts="true" option.
Short term copy Liberty JRE cacerts file to JazzTeamServer\server\liberty\servers\clm\resources\security and reference from a defaultTrustStore entry in server.xml: <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" sslProtocol="SSL" enabledCiphers="blah blah"/> <keyStore id="defaultKeyStore" location="ibm-team-ssl.p12" type="PKCS12" password="{xor}Nj0ycis6PjI="/> <keyStore id="defaultTrustStore" location="cacerts" type="JKS" password="changeit"/> |
2 other answers
Ian Barnard (2.3k●7●14)
| answered May 13 '20, 7:16 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited May 13 '20, 8:14 a.m.
Hi Ian
I see that exact message in my 7.0 test environment too - my working theory is that these messages are due to the default certificate being self-signed and possibly also because it uses hostname localhost. As the certificate in the default install couldn't be anything but self-signed, you are always going to get these messages until you install a full CA certificate - that's why this is a theory: I have no possibility of using a CA certificate.
I don't think this is new in 7.0, though - AFAICT my test env has the exact same message in at least 6.0.4, 6.0.5, 6.0.6 and 6.0.6.1 - these have a self-signed cert but at least with the host name in the cert corrected to be not "localhost" unlike my 7.0 setup which uses the default .p12 file like you are doing.
One thing that has changed for 7.0 is that the default keystore is now in PKCS12 format - so server.xml has changed on the <keystore…/> line - but I believe you can still edit this line and use JKS/JCEKS format as per older server.xml. Anyway this also won't affect the error message you are seeing.
HTH
Ian
Comments CA Certs don't solve the problems. I have never used self signed or default certs. This problem began recently on both 6.0.6 (after going from iFIx 13a to 15) and 6.0.6.1 (after going from iFix 6 to 9).
I see untrusted IBM certs and my company, though the company are NOT from the trust as the CA certs installed or part of their trust chain.
|
As a result of open cases for both CLM and Installation Manager I was able to resolve this and learned. <o:p> </o:p> 1. IBM started redirecting all http traffic to https about April 2020. <o:p> </o:p> 2. WLP has a defect that causes cacerts to be disabled if a custom keystore is used. <o:p> </o:p> 3. CLM Help performs a handshake with ibm.com when starting up. <o:p> </o:p> a. Before the https redirects began it worked fine using http. <o:p> </o:p> b. Once redirected to https the handshake fails. <o:p> </o:p> c. One cause is the WLP defects preventing access to cacerts when a non-default keystore is used. <o:p> </o:p> i. With http the cacerts defect was mute. <o:p> </o:p> ii. The defect is resolved somewhere around WLP 19.0.0.9 (after ELM 7.0) so out of the box with ELM 7.0.1 (WLP 20.0.0.3). <o:p> </o:p> iii. I resolved with earlier CLM version by adding the necessary certs to my custom keystore. <o:p> </o:p> 4. Fixing IBM’s trust chain in cacerts still resulted in failure in our environment. I was experiencing similar behavior with Installation manager being unable to connect to online repositories using SSL. <o:p> </o:p> a. The cause in my case was proxy certs. My company issues proxy certs at the firewall, so the IBM DigiCert cert never gets to IM or CLM (I get a cert issued to <ibm.com> by <myCompanyprivateInternalCA>). So missing IBM’s trust chain was irrelevant. What was relevant was my company’s private CA trust chain was not in cacerts (as it should be). <o:p> </o:p> b. Resolved by adding the private root to my custom keystore for CLM, WAS, IHS, and JAS and to CA certs for IBMIM. <o:p> </o:p> Comments > IBM started redirecting all http traffic to https about April 2020
I guess you mean http://ibm.com redirects to https://ibm.com
You are correct. Sorry for the ambiguity. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
java.security.cert.CertPathValidatorException: Certificate chaining error com.ibm.ws.ssl.core.WSX509TrustManager checkServerTrusted