Expand my Community achievements bar.

Guidelines for the Responsible Use of Generative AI in the Experience Cloud Community.

Handling “javax.net.ssl.SSLHandshakeException” in Java for AEM inter-server communication. | AEM Community Blog Seeding

Avatar

Administrator

BlogImage.jpg

Handling “javax.net.ssl.SSLHandshakeException” in Java for AEM inter-server communication. by Umesh Thakur

Abstract

I was setting up one dispatcher flush agent in one of my publisher server to implement a real scenario. After entering values in all the required fields, when I click on the Test Connection on the result page it says “Replication test failed“

After looking into the stack trace I was surprised and clueless as the required certificate was present and active on my dispatcher server.
Stack trace:
Error while sending request: 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 doing some google, I came to know that though you have certificate present there on your application server and not expired as well, java(JRE) installed, on which your AEM instance is running, is not recognising because those certificates were self signed.

Now the question is, how to make java to trust the certificate?
Lets find out the answer
To make your Java Runtime Environment trust the certificate, you will have to import the certificate into the JRE certificate store.
Steps to import the certificate to the JRE certificate Store:
First, you need to download the certificate in your local machine after opening the site in any browser. Path for the certificate can be different in different browser. like in Chrome you can find it in, Chrome Customise →More Tools →Developer Tool →Security Tab → View Certificate button. Then drag the certificate in somewhere in your machine.

Read Full Blog

Handling “javax.net.ssl.SSLHandshakeException” in Java for AEM inter-server communication.

Q&A

Please use this thread to ask the related questions.



Kautuk Sahni
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

6 Replies

Avatar

Level 5

Hi @kautuk_sahni @Umesh_Thakur,

We are facing same exception while connecting to Service Layer APIs with domain for example services.companyname.com from AEM instance.

Do we need to add the certificate in AEM Global Trust Store?

Adding certificate to AEM Global Trust Store and adding on the server, on which AEM and Java are installed, how are these both different?

Below is the exception stack trace

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
	at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)

 

Avatar

Community Advisor

Hi @srikanthpogula ,

The issue, you mentioned, is the same issue explained in the blog. 

Let me make it clear once more, the problem was associated with the JRE not directly with AEM so you need to provide a fix for the JRE, on which you AEM instance is running.

In the case of handshake your JRE is not recognising the target instance certificate and so it is throwing the exception.

Once you make your JRE recognise the certificate of the target  server your issue will resolve.

Please follow the steps given in the blog.

Hope this helps

Umesh Thakur

Avatar

Level 5

Hi @Umesh_Thakur ,

Thanks for the response.

I did follow the blog and add the certificate to JDK (not JRE) cacerts file on the server where AEM is installed but the issue still exists.

I could not find JRE path on the server (it is an AMS maintained AEM instance). I found the java/JDK path with the help of command whereis java. Could this be an issue that I added certificate to JDK instead of JRE?

 

Thanks

Srikanth

Avatar

Community Advisor

If you have JDK, then definitely you will have jre as well, please try to locate. path will be like  /app/temp/jdk/jdk1.8.0_191/jre/lib/security/cacerts 

Since this is an Adobe Managed instance, I would recommend you to raise this concern with the adobe support to fix the issue as a whole if not then at least they will help you to locate JRE.

Hope this will be helpful to you.

Umesh Thakur

Avatar

Level 5

Hi @Umesh_Thakur 

Below is the only place on AMS publish instance where I could see JRE /usr/java/jdk1.8.0_251-amd64/jre/lib/security/cacerts.

I imported the cert by running the keytool import command and did an AEM instance restart but still see the same issue.

Is server reboot required after adding the certificate to JRE cacerts?

This is the java version output

java version "11.0.5" 2019-10-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.5+10-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.5+10-LTS, mixed mode)

Avatar

Level 5

We were able to get this to work (issue not fixed yet) by changing the runmode of AEM publish instance to stage from prod i.e. we are maintaining the Service Layer API URLs in runmode OSGI configurations. So if configurations in config.stage.publish has services.mycompany.com URLs, we were able to get it to work without SSLHandshakeException. It is strange and we could not understand what might be the actual issue.

With runmode as config.prod.publish, we are getting SSLHandshakeException.

 

Thanks

Srikanth Pogula.