I'm using a free SSL-cert from startssl.com for my Artifactory-repo. It's all green and nice in my browsers, but of course not from Java. So I installed the cacerts with this handy script:
http://www.ailis.de/~k/uploads/scripts/import-startssl
But I STILL get the:
Server access Error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException
error. JAVA_HOME set correctly. Any suggestion highly appreciated!
More info:
Its Ivy from SBT 0.12.2 (using pualp's script https://github.com/paulp/sbt-extras) that is barfing on the cert:
[info] Resolving net.liftmodules#omniauth_2.10;2.5-SNAPSHOT-0.7-SNAPSHOT ...
[error] Server access Error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target url=https://repo.woodenstake.se/all/net/liftmodules/omniauth_2.10/2.5-SNAPSHOT-0.7-SNAPSHOT/maven-metadata.xml
--
Update:
The problem seems to be something totally different not related to Java per se. Visiting the page from a browser yields a green cert and I can see the info that its signed from StartSSL. But even wget or curl chokes and tells me that this is a self-signed cert. It seems that different certs are delivered depending on the client.
The repo is at https://repo.woodenstake.se/ - If you paste this in your browser I would guess that you get the StartSSL-cert. BUT if you do wget https://repo.woodenstake.se/ you get some old self-signed cert that I don't know where it comes from.
-- Update to update:
So the problem is that I'm serving a few sites of the form *.woodenstake.se. I got the feeling that it would be possible to have different certs like:
server {
listen 443;
server_name site1.woodenstake.se;
client_max_body_size 512m;
ssl on;
ssl_certificate cert1.crt;
ssl_certificate_key cert1.key;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://server1;
break;
}
}
}
server {
listen 443;
server_name site2.woodenstake.se;
client_max_body_size 512m;
ssl on;
ssl_certificate cert2.crt;
ssl_certificate_key cert2.key;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://server2;
break;
}
}
}
and it works just fine in all my browsers.
However, it doesn't work from wget or JDK6.
Problem was something completely different. Apparently you can't have more than one certificate on the same IP and be sure that all clients can handle it. I have a few tools on this machine and my nginx-config had references to both the StartSSL cert for this site but also to a self-signed (snakeoil) cert for some other sites.
My nginx supports TLS SNI:
~ $ sudo nginx -V
nginx version: nginx/0.7.65
TLS SNI support enabled
but apparently wget and Java clients doesn't handle it. All my browsers do though.
Maybe it's possible to do something like:
http://library.linode.com/security/ssl-certificates/subject-alternate-names
but I don't know if it is possible to get StartSSL to sign it.
More info here:
http://www.carloscastillo.com.ar/2011/05/multiple-ssl-certificates-on-same-ip.html
Wget test on my Ubuntu-desktop:
viktor#hedefalk-i7:~$ wget https://bob.sni.velox.ch/
--2013-03-25 17:07:19-- https://bob.sni.velox.ch/
Resolving bob.sni.velox.ch (bob.sni.velox.ch)... 62.75.148.60
Connecting to bob.sni.velox.ch (bob.sni.velox.ch)|62.75.148.60|:443... connected.
ERROR: no certificate subject alternative name matches
requested host name `bob.sni.velox.ch'.
To connect to bob.sni.velox.ch insecurely, use `--no-check-certificate'
So I think the answer to my question is
Your version of Java (or all, but maybe it works in JDK7: http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html) doesn't support TLS SNI so nginx can't be sure which certificate to serve since this is negotiated before http. Buy a wildcard-cert for real money from the man or cry a river.
Related
Charles 4.6.2, macos 12.1
Following this page, https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/
I tried the following steps:
help->ssl proxying->save charles root cert
find where java lives: /usr/libexec/java_home
cd /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/lib/security
sudo keytool -import -alias charles -file ~/Documents/charles-ssl-proxying-certificate.pem. THis prompts for 3 passwords, which I created new/radom passwords for (dont know what they are)
start java thusly: java -jar aem-publish-p4503.jar -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8888
in charles proxy->ssl proxy settings Check Enable proxy settings.
Add URLs in "include" which the java server will call with port 443.
Now when my java app tries to hit api end points I added to the SSL proxying location, I get the following in the charles proxy sequence output:
URL https://npxx.net
Status Failed
Failure SSL handshake with client failed: An unknown issue occurred processing the certificate (certificate_unknown)
Notes You may need to configure your browser or application to trust the Charles Root Certificate. See SSL Proxying in the Help menu.
Response Code 200 Connection established
Protocol HTTP/1.1
In java logs, I see this:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"
NOTE: the external end point the local java process is hitting has a wild card Multi SAN cert from comodo
=== UPDATE 1 ====
I found an undocumented way to add certificates, in charles proxy, there are some cert install options under help:
Help->SSL proxying->Install Charles Root Cert.
This does nothing. Presume it doesnt work on mac
Help->SSL proxying->Install cert on Java VMs
This does work, and prompts for password, then says complete, but doesnt help.
Recently the cert got expired both on Jenkins server (Linux) and IIS server (windows) and we have imported the new certs for both Jenkins and remote slave.
post that it was able to connect when we launch through browser (but pop up with java - (The certificate is not valid and cannot be used to verify the identity of this website) and if we install Jenkins as a service on windows machine it was in starting state (not proceeding with the Running state) and unable to start the Jenkins as slave in logs
i can see this error as following:
"Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"
Your certs are not correct. Make sure the values for CN and hostname on the cert you imported are the same as the old cert. Make sure you have the intermediate and root certificates imported/trusted as well, as those may have changed with the new certs.
Windows: certlm to check that the intermediate and root certificates are also trusted.
I am new in JAVA, Consuming web service(.wsdl) in Web Service Client project. I import the client certificate in java cacerts store in jrd. My code is as follows:
System.setProperty("javax.net.ssl.trustStore","[PATH]/cacerts.jks");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
ServicesProxy service = new ServicesProxy();
ServiceRequest request = new ServiceRequest(1498);
ServiceResponse response = service.getDetails(request);
I'm failed to handshake, I am getting the following exception:
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
I have no clue why there is an exception. Any help will be appreciated.
You probably have to add the key chain in the certificate (PEM format).
CA Root -> Intermediate Cert -> Cert.
Or the certificate cannot be found in the keystore, do you use the correct alias etc.
And I do not recognize the SOAP JAX-WS implementation you use.
Not a solution to your problem, but maybe it helps to find it:
You can start your client with the VM parameter -Djavax.net.debug=all which will give you a lot of information about the SSL connection.
Check here for details about the output:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
Use -Djavax.net.ssl.trustStore property directly instead.
One more thing the server you use in that also u need to place the jks for handshake.
For example server is JBoss then bin
I guess your cacert is not correct or the path is unaccessible. I followed the instructions given here
Use SSL Poke to verify connectivity
Download SSLPoke.class
Execute the class as follows, changing the URL and port:
$JAVA_HOME/bin/java SSLPoke yoururl 443
A successful connection would look like this:
$JAVA_HOME/bin/java SSLPoke yoururl 443
Successfully connected
Try to use a different truststore to connect
$JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=[PATH]/cacerts.jks SSLPoke yoururl 443
If it fails the truststore does not contain the proper certificates.
How to solve it
The solution is extracted from here
Fetch the certificate again from the server:
openssl s_client -connect yoururl:443
You need openssl. Save the output to a file called public.crt. This is how your file should look like:
-----BEGIN CERTIFICATE-----
< Bunch of lines of your certificate >
-----END CERTIFICATE-----
Import the certificate:
$JAVA_HOME/bin/keytool -import -alias -keystore $JAVA_HOME/jre/lib/security/cacerts -file public.crt
Enter the password if prompted (the default is changeit)
Recommendation
In the same post it is not recommended to use a configured trustStore different than the JVM cacert because then java could not access other root certificates.
This is a quite common error while dealing with soap services over SSL, I've had it a few times.
Your certificate may not be correctly installed in your truststore.
You can use openssl to check and install the correct certificate in the truststore, as explained here
Hi Looks like certificates are not imported correctly or path used in code not pointing to correct keystore.
I hope following steps in below article will help you.
http://magicmonster.com/kb/prg/java/ssl/pkix_path_building_failed.html
I'm a bit lost of how I can use certificate in WidlFly 11. I re the doccumentation and found a lot of terms like JSSE, OpenSSL, Elytron, ApplicationRealm.
The problem occurs when I execute the code
final URL url = new URL("https://someUrl");
HttpsURLConnection httpURLConnection = (HttpsURLConnection)url.openConnection();
This exception is thrown sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
So, what exactly need to configure? I tried the section "Enable One-way SSL/TLS for Applications" in Elytron Doccumentation but didn't works.
ps: I'm using java 9.01
ps2: I'm using standalone-full.xml
let me know if you need more informations
This is unrelated to WildFly - you need to configure certificates trusted by java URL connections - you need to create and configure truststore:
create keystore containing certificate of server (if it is self-signed certificate), or better, certificate of its CA:
keytool -import -file myCA.cert -alias myCA -storepass mypassword -noprompt -keystore my.truststore
start using created keystore file as truststore in WildFly by setting javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword system properties:
bin/jboss-cli.sh -c
/system-property=javax.net.ssl.trustStore:add(value="/path/to/my.truststore")
/system-property=javax.net.ssl.trustStorePassword:add(value="mypassword")
Elytron documentation you mention is related only to server side - but this is client side configuration, which is not currently handled by it.
The certificate is not trusted, iirc there is a self-signed certificate in WildFly 11 so yo need to trust it or install a real certificate.
Accept server's self-signed ssl certificate in Java client
Installed a tomcat environment on my test server (Fedora 26). Everything is stock package. I've also installed and setup Nginx reverse proxy on the front. tomcat-users.xml is set and I can login to the app manager as expected.
Now, when I try to deploy a WAR to it, I get critical failure on my Nginx log:
2017/09/25 15:12:21 [crit] 13878#0: *36 open() "/var/lib/nginx/tmp/client_body/000000XXXX" failed (13: Permission denied), client: 200.x.x.x, server: some-sandbox.com, request: "POST /manager/html/upload?org.apache.catalina.filters.CSRF_NONCE=XXXXXXXxxxx HTTP/1.1", host: "some-sandbox.com", referrer: "https://some-sandbox.com/manager/html/upload?org.apache.catalina.filters.CSRF_NONCE=XXXXXXXxxxx
Nginx then return 500 internal server to browser.
What could I have get wrong? Any suggestion how to tackle?
Thanks.
Apparently there is some permission issue with the temporary upload folder /var/lib/nginx/tmp. I've made sure that the whole path is owned by the correct system user. But the issue still exists.
So to circumvent the issue, I decided to config Nginx to skip caching the client body at all. For my purpose, there is no practically value to cache before proxying.
Nginx 1.7.11 introduced a new proxy_request_buffering directive. If you set it to off, the buffering would be disabled. And hence any permission issue would not affect the upload.
So my server section has this:
location / {
proxy_request_buffering off;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080/;
}
You can check the user privilage on the file for current user.