I am trying to run the driver-Java-code locally inside my Windows-Eclipse and attempting to make the HTTPS call to a webservice deployed in a different Windows-Alfresco server.
The webservice deployed in the Windows-Alfresco server is created using Java-backed-WebScript. The webservice URL attempted to be called is similar to: https://mydomain.org/alfresco/service/extract/abc
This is what I have attempted:
I took the valid certificate from the Alfresco-Windows server and added to my local-Eclipse-Windows machine’s JRE using the following:
keytool -import -trustcacerts -alias mycertificate -file C:\Documentation\ mycertificate.cer -keystore keystore.jks
After that, I also made sure that the certificate is indeed installed and verified that using:
keytool -list -v -keystore keystore.jks
I also verified that Eclipse is also configured to use the same JRE, where I imported the certificate from Alfresco.
Even with that, I still get the error as follows, when I attempt to execute the Java-client-code from my Windows-Eclipse, attempting to call the URL deployed in the remote Windows-Alfresco server:
Called URL =https://mydomain.org/alfresco/service/extract/abc
I get exception stacktrace as:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.jav...)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at MyDreiver.java:63)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
... 15 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
... 21 more
My question:
1. Any suggestion will be appreciated.
When you do calls to HTTPS URLs protected by self-signed or other untrusted certificates, you should never rely on the certificate being added to the JRE. Instead, you custom code should use its own truststore for certificate / host validation, i.e. similar to how Alfresco uses the ssl.truststore for handling the SSL certificate validation if SOLR and Repository are set up in a mTLS configuration.
Hello Afaust,
Thanks for the response.
Alfresco-Windows-machine has a correct certificate and has no issue.
I issue is, not being able to call a URL (URL is hosted in that Alfresco-Windows-machine) from a different Windows-machine, where I run local-Java-code in Eclipse. I obtained the correct certificate from the Alfresco-Windows-machine. After that, I attempted to install that certificate in the JRE of the local-Java-Eclipse-machine. The local-Java-Eclipse-machine has Java driver code (e.g. Java main method) that calls URL hosted in Alfresco-Windows-machine. The local-Java-Eclipse-machine does NOT have any server, or anything else, only has a Java-driver class that can make HTTP(s) call to the URL hosted in Alfresco-Windows-machine. The local-Java-Eclipse-machine (even with the certificate installed in its JRE) is not being able to succeed in calling the URL of the Alfresco-Windows-machine.
My questions:
1. Are you suggesting any different configuration in local-Java-Eclipse-machine, which only has the has the Java driver (it does not have Alfresco, does not have Tomcat). It simply makes the HTTP(S) calls the URL hosted in the Alfresco-Windows machine.
2. I do not understand what exact SOLR-type configuration you are suggesting for the local-Java-Eclipse-machine.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.