Prospect review

Because the company’s project needs, it needs to connect with Amazon IOT and send messages to Amazon IOT. It uses Amazon’s SDK. Everything seems normal. However, the test service reports an error and the local environment is normal.

Local JDK configuration:

java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)

JDK configuration of test service:

openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing)

Is there a big difference?There is no big difference. Oracle jdk11 is used locally. The server uses openjdk11 because it knows why. That’s all, but the program will always report an error:

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

solve the problem

First changed a configuration

Find a link, which is a link on the official website of Oracle. The description of Oracle certificate roughly means that Oracle JDK will no longer trust the TLS certificate issued by Symantec, which is consistent with the similar plans recently announced by Google, Mozilla, apple and Microsoft. If necessary, you can bypass these restrictions by commenting out or deleting “symantec_tls” in the jdk.security.cadisttrustpolicies security attribute of the java.security configuration file.

https://blogs.oracle.com/java/post/oracles-plan-for-distrusting-symantec-tls-certificates-in-the-jdk

The above configuration is in Java_ The file home/conf/security/java.security is opened in the form of text. It is around line 1187. There is such a sentence JDK. Security. Cadistrustpolicies = Symantec_ TLS needs to be commented out and changed to the following:

#jdk.security.caDistrustPolicies=SYMANTEC_ TLS

Then, then the server still can’t, Gan!

In the middle, I made a lot of attempts, but I didn’t describe it in detail. Finally, I was surprised and did a magical operation!

Then replaced a file

In Java_ Home/lib/security/cacerts file. This file is mainly a warehouse used by JDK to store certificates, including self trusted certificates and some certificates imported by keytool. Then I used Oracle cacerts certificate to replace the file with the same name under the same path of openjdk on the server. OK, done!

Problem estimation

Through the keytool – List – keystore cacerts command to view the two files, it is found that the date of the oreclejdk is irregular and the date is relatively long, while the date of the openjdk is 2021. I don’t know if it has anything to do with this problem. If I encounter it at present, I’ll remember it first and make a note.