Hi folks,

Yesterday morning, We suddenly can not access to Salesforce. We are using https REST API with DegiCert Global Root CA TLS1.2. We find following alart message on EPM Alarm screen: "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".

After many time I restarted web application server(restart tomcat service), communication failure has recovered and there are no errors now.

Does anybody know why it occurred? Salesforce said there are no maintenance operations.
Any ideas?

Thank you.

Hello.

Did you make any change before restarting Tomcat ?

As I know, this problem can appear when you are using a self-signed certificate. Did you check certificates ? There are many tips online on how to fix, just googling.

Hello,massimo

Thanks you for your reply.

I did not change before restarting Tomcat.

And I use "DegiCert Global Root CA" ,expiration date from 2006/11/10 to 2031/11/10 ,downloading from Salesforce website. It is not self-signed certificate.

In this case,WAS server communicate to Salesforce. There are few tips online.

Is there anything else I can do?

Hello,folks

Are there anything software bugs about runtimeconfig ,managing certificate?

(AEP)
EPM 7.2.1.0.0605

(runtimeconfig)
Framework runtime version(scert.jar):07.21.5.09
Framework runtime common version(scertcommon.jar):07.20.09.04
Java version:1.8.0_191


Time sequence
-----------------------
1.2020/11/14 22:00(JST)
We replaced new application in the Tomcat Web Application Manager
And we rebooted the two WAS servers.

2.2020/11/15 4:00(JST)
No Good(Unable to access Salesforce)
We found this message in the two WAS servers.
"javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"

Then we restarted the tomcat service in the two WAS servers..
OK

3.2020/11/15 6:15(JST)
No Good(Unable to access Salesforce)
We found this message in the two WAS servers.
"javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"

We replaced old application in the Tomcat Web Application Manager
And we restarted the tomcat service in the two WAS servers..
OK

4.2020/11/15 14:23(JST)
No Good(Unable to access Salesforce)
We found two , this messages in the one WAS server.
"javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"

5.2020/11/15 14:24(JST)
OK(Automatic recovery)
-----------------------

There is not any issue that I know of. The main thing Runtimeconfig does is adding the certificate to the trust store file. By default Runtimeconfig is pointing to the trusted_weblm_certs.jks and new certificates to it. The OD runtime just looks into this file for matching certificates. You can also try using a different trust store file by changing it in Runtimeconfig.

Hello,WilsonYu

Thank you very much for kind reply.

I found out the issue that I recreate.

Please refer to the following.
1.I made a different trust store file.
2.And I go to the License Server Parameter page.
3.Next I access to the Certificates page.
4.Certificate keysotre(javax.net.ssl.trustStore's value) is automatically changed default for Weblm.
5.Then a failure occurs until we restart the tomcat service.

Are there anything software bugs about OD or access to the WebLM(SMGR)?

SR Number is SR#1-16994972857.

If you have a different truststore file, you need to change the default to point to that file. I don't know of any bug that would reset to the default automatically.

Thanks a lot.

I had a different truststore file in the OD Certificate page.
But No change.

Is there anything else I can do ?

The only thing i can think of is the certificate doesn't work.

Hello WilsonYu,

Thanks for your support on this case.

Regarding this case, we found javax.net.ssl.trustStore has changed from "/opt/tomcat/conf/myTrustStore" to "/opt/apache-tomcat-8.5.31/lib/trusted_weblm_certs.jks" in OD > Certificates.
And it seems the cause of this issue (= Salesforce HTTP request failure).

As reference, please confirm attached "OD_01.png" and "OD_02.png".

We'd like to know is there any possible cause or any errors in this OD (= 07.20.09.04)?
This javax.net.ssl.trustStore path change occurs suddenly after the user performed following activity:
=====
1. Application deployment from Tomcat Manager
2. After deployment completes, the user performed WAS (OD) server reboot
?
?# HTTP request failure occurs
?
3. As workaround, the user performed Tomcat service restart, then the issue has restored.
4. Rollback to previous application from Tomcat Manager
?
5. But the issue repeats randomly.
# As workaround the user performs Tomcat service restart to restore.
6. Now the user found javax.net.ssl.trustStore has changed from "/opt/tomcat/conf/myTrustStore" to "/opt/apache-tomcat-8.5.31/lib/trusted_weblm_certs.jks" in OD > Certificates. (Now we're here)
=====

Yes, there was a problem like this in 7.20. Try upgrade OD to 7.21 or 7.23 the latest.

Hi WilsonYu,

Thank you for your reply.

Is there any description about this in Release Notes or any case number to see details?

I already checked the Release Note before, but I couldn't find similar description of our case.

We took care of the issue during the development cycle right after the release of 7.2. I can assure you this is the case since I can trace the code change we made on the issue. We typically don't include it in the release notes if it a bug we found and fixed internally.

Hello WilsonYu,

I really apprecaite your reply.
Understood.

But I tried using OD 7.2.1 ,but in it does not work.
The event remains the same.

Could you think of anything that might have caused it?

Same as what you described here?

6. Now the user found javax.net.ssl.trustStore has changed from "/opt/tomcat/conf/myTrustStore" to "/opt/apache-tomcat-8.5.31/lib/trusted_weblm_certs.jks" in OD > Certificates. (Now we're here)
=====

Can you make sure in the Tomcat/lib you have the scertcommon jar for 7.2.1 and no other version of scertcommon and you have restarted the app server?