Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

SSL handshake failure reported on starting ELM 7.0

Questions
Tags
Users
Badges
Ian Wark
(797●1●35●53) edited
May 12 '20, 8:05 a.m.

<Environment>
Windows Server 2016
Liberty
Derby
ELM 7.0 (no iFix)


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.

0 votes

Comments
Ian Wark
May 12 '20, 8:15 a.m.
FFDC is reporting that the certicate is not trusted.

java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
    java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
    java.security.cert.CertPathValidatorException: Certificate chaining error com.ibm.ws.ssl.core.WSX509TrustManager checkServerTrusted

3 answers
2,803 views
0 votes

Accepted answer

Permanent link
Guido Schneider
(3.4k●14●91●115) May 13 '20, 4:02 p.m.

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

0 votes

Comments
Ian Wark
May 14 '20, 3:21 a.m.

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:

C:\Program Files\IBM\JazzTeamServer\server\jre\bin>keytool -alias digicertglobalrootca -list -v -keystore "C:\Program Files\IBM\JazzTeamServer\server\jre\lib\security"\cacerts


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?

Ian Wark
May 28 '20, 1:56 a.m.
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

Permanent link
Ian Barnard
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (2.4k●7●14) 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

1 vote

Comments
james wetzel
May 29 '20, 2:22 p.m.

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. 

Permanent link
james wetzel
(97●1●2) Jul 16 '20, 4:46 p.m.

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>

1 vote

Comments
Ian Barnard
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jul 17 '20, 12:12 p.m.

>   IBM started redirecting all http traffic to https about April 2020


I guess you mean http://ibm.com redirects to https://ibm.com


james wetzel
Jul 17 '20, 12:31 p.m.

You are correct. Sorry for the ambiguity.

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 7,498
× 2,357
× 1,328

Question asked: May 12 '20, 7:55 a.m.

Question was seen: 2,803 times

Last updated: Jul 17 '20, 12:31 p.m.

Confirmation Cancel Confirm