javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated at java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:556) at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.verifyHostName(SSLProtocolSocketFactory.java:257) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:115) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at com.day.commons.httpclient.impl.JDK7SSLProtocolSocketFactory.createSocket(JDK7SSLProtocolSocketFactory.java:99) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:156) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at com.day.commons.httpclient.impl.JDK7SSLProtocolSocketFactory.createSocket(JDK7SSLProtocolSocketFactory.java:88) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:714) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:394) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:178) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:404) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:330) [com.day.commons.osgi.wrapper.commons-httpclient:3.1.0.28]
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @mohammed9109 ,
As mentioned by @cshawaus it is really impossible to identify the actual root cause of the issue unless there is a use-case scenario. But to the best of my knowledge, I have identified a few possible situations for the same error.
The javax.net.ssl.SSLPeerUnverifiedException
is thrown when there is an issue with the SSL/TLS certificate being used for an HTTPS connection. One common cause of this exception is that the certificate presented by the server is not trusted by the client.
Here are a few things you can check:
Make sure that the server's certificate is installed in the truststore of the JVM that is running AEM. The truststore typically contains a collection of trusted root CA certificates and is used by the JVM to verify the authenticity of the server's certificate.
Check the certificate chain, Make sure that the certificate presented by the server is signed by a trusted CA and that the entire certificate chain is valid.
The certificate might be expired, make sure that the certificate is not expired and that the clock on the server is correct
Verify that the hostname in the server certificate matches the hostname of the server you're trying to connect to.
Check the configuration, ensure that the client and server are using compatible SSL/TLS protocols and ciphers.
You may also find that you need to import the server's certificate or CA chain into the JVM truststore using the keytool command. This command can be used to import, list, and manage certificates and private keys in a JKS keystore.
If none of the above solutions help, You may want to try importing the server's SSL certificate and adding it to the AEM truststore, which is located in the crx-repository folder, this will help to create a trust relationship between the client and server
It's also possible that the error message is indicating a different problem, and you may need to look into other areas of the system, such as network configurations, firewall rules, or load balancers. In this case, you should check the error logs and troubleshoot accordingly.
Hope this helps !
Thanks,
Ravi Joshi
@mohammed9109 Without knowing what you are attempting to connect to or any code to review, it is impossible to understand the potential cause. However, the likely cause is due to a certificate that is:
Beyond this it is not possible to provide an answer with certainly without completely knowing the context.
Hi @mohammed9109 ,
As mentioned by @cshawaus it is really impossible to identify the actual root cause of the issue unless there is a use-case scenario. But to the best of my knowledge, I have identified a few possible situations for the same error.
The javax.net.ssl.SSLPeerUnverifiedException
is thrown when there is an issue with the SSL/TLS certificate being used for an HTTPS connection. One common cause of this exception is that the certificate presented by the server is not trusted by the client.
Here are a few things you can check:
Make sure that the server's certificate is installed in the truststore of the JVM that is running AEM. The truststore typically contains a collection of trusted root CA certificates and is used by the JVM to verify the authenticity of the server's certificate.
Check the certificate chain, Make sure that the certificate presented by the server is signed by a trusted CA and that the entire certificate chain is valid.
The certificate might be expired, make sure that the certificate is not expired and that the clock on the server is correct
Verify that the hostname in the server certificate matches the hostname of the server you're trying to connect to.
Check the configuration, ensure that the client and server are using compatible SSL/TLS protocols and ciphers.
You may also find that you need to import the server's certificate or CA chain into the JVM truststore using the keytool command. This command can be used to import, list, and manage certificates and private keys in a JKS keystore.
If none of the above solutions help, You may want to try importing the server's SSL certificate and adding it to the AEM truststore, which is located in the crx-repository folder, this will help to create a trust relationship between the client and server
It's also possible that the error message is indicating a different problem, and you may need to look into other areas of the system, such as network configurations, firewall rules, or load balancers. In this case, you should check the error logs and troubleshoot accordingly.
Hope this helps !
Thanks,
Ravi Joshi
Views
Likes
Replies