I have a server running on Dropwizard (i.e. running Jetty for its web server). I'm trying to set up SSL for it.
I have a certificate signed by a CA (specifically Comodo, through Namecheap). I installed the root and intermediate certificates, then installed my own certificate (using the instructions on Comodo's support. Nonetheless, when I attempt to connect to my server for the first time (it boots fine), I get an error: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (Of course the stack trace is much longer, but that's the root cause.)
I've tried searching this error, and consistently people say it should only happen for self-signed certificates, which mine is not. Nonetheless, I tried downloading the InstallCert.java program that seems to have originated from a (now removed) article on the Sun blog. Specifically I got the degree from this page.
After several (failed) attempts to get it to work by command line (that's a discussion for another time), I eventually got it to run properly. Now the output I get from the program is:
Loading KeyStore C:\Program Files\Java\jdk1.8.0_05\jre\lib\security\cacerts...
Opening connection to localhost:8443...
Starting SSL handshake...
Exception in thread "main" java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
at com.aw.ad.util.InstallCert.main(InstallCert.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Process finished with exit code 1
Meanwhile, if I open the window with my website, it once more delivers the unable to find valid certification path to requested target error and crashed (hence leading to the timeout). In essence, what it seems to me is that InstallCerts (which should fix my SSL problems) is crashing my server due to the SSL issues.
If I try using something like openssl s_client -connect localhost:8443 -showcerts (which was a recommendation I saw somewhere, save the results of that to a .pem file and install that), the same thing happens.
Is there a solution this problem? Am I missing something obvious here?
You might be missing the whole chain of certificates from Comodo root CA to your site's certificate. Examine the keystore that you configured in Dropwizard and see if you have them all. The simplest way is to look for the issuer of your certificate, you need to have the certificate with the same subject, next look for the issuer of that certificate and so forth. To be sure try to chain authority key identifier certificate extension of your certificate with the key fingerprint (key identifier) of the issuer, and the issuer's issuer. If you provide
keytool -list -keystore <your keystore> -rfc
I might be able to help you more...
Added later:
I've managed to reproduce your problem exactly. TL;DR; add:
validateCerts: true
trustStorePath: lyonesgamer.com.keystore
enableCRLDP: true
I created a keystore containing the chain (single entry, 3 certificates, ca, subordinate ca and end entity certificate) and another keystore containing only the two ca certificates as trusted entries. Then I configured keyStorePath, keyStorePassword, trustStorePath and validateCerts: true.
This resulted in:
java.security.cert.CertificateException: Unable to validate certificate: unable to find valid certification path to requested target
After adding -Djava.security.debug=certpath I noticed that revocation checking was failing, and that this in fact was the root cause of certificate chain failure:
certpath: SunCertPathBuilder.depthFirstSearchForward(): validation failed:
java.security.cert.CertPathValidatorException: Could not determine revocation status
Then I remembered that if you do not enable CRL Distribution Point extension usage for the CertPath API you need to specify the CRL yourself. Fortunately Dropwizard has an option to enable the CRLDP: enableCRLDP: true. With it enabled application successfully starts.
Alternatively you could keep the CRL in a file and point crlPath to it.
After all this time, I'd been chasing a rabbit hole. It turned out the problem was that I (rather naively) was testing this on my own computer. Dropwizard's validation saw an error, because the certificate was only valid for my domain, which my personal computer is not a member of. Hence it crashed because it couldn't validate.
I discovered this by turning validateCerts off in my Dropwizard config file (I had thought I'd turned it off already, but apparently not). Dropwizard booted fine and allowed me to connect. When I did, then Firefox gave me an Untrusted Connection error, and clicking on Details gave me the much more useful information:
localhost:8443 uses an invalid security certificate.
The certificate is only valid for the following names: lyonesgamer.com, www.lyonesgamer.com
(Error code: ssl_error_bad_cert_domain)
Thank you, Zoran, very much for trying to help. I'm afraid much of it was in vain.
Related
As part of updating the SSL/TLS certificate of the web server deployed in the Kubernetes(which the current one will expire soon), I updated the Kubernetes secret (kubernetes.io/tls) with the new crt and key.
After that, the application works fine in the browser.
But, the API calls to the server, (From some python applications running in some pods) are hitting some SSLError.
The same will work if I restore the old certificate for the server.
The error is:
requests.exceptions.SSLError: HTTPSConnectionPool(host='hostname',
port=443): Max retries exceeded with url: URL(Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate
(_ssl.c:1131)')))
I tried to resolve this by creating the crt and key in different ways from the pfx file.
But the issue remains.
I did some search on - if anything to update in the Kubernetes cluster as part of the certificate change and I couldn't find a solution.
Any help will be greatly appreciated.
The issue was, the certificate I installed was without the intermediate certificate. The browsers may "fill in the gap" by searching for the missing certificate. Re-install the certificate with the complete chain resolved the issue
Error message: SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I been trying to configure the proxy correctly but some http servers respond with success, meanwhile all the https doesn't.
I installed all the necessary plugins manually for run a sample pipeline but the error in console output is just a nested page 404 by jenkins.
It's important to know that my OS have the cli internet connection blocked for security terms.
This is the last followable trouble that I have, but I'm a little bit confusing with the SSL cert, I tried to resolve it by this post but is not clear to me which SSL cert I have to download and if this could cause troubles with my PC restrictions.
One solution to resolve this issue is change the update url at management plugins > advanced setting > url update from this
https://updates.jenkins.io/update-center.json
to this
http://updates.jenkins.io/update-center.json
this solutions is not definitive and i won't recommend it.
Actually i solve this problem loading the plugins.jenkins.io cert to the javas's keystore using
.\keytool.exe -import -alias {alias} -keystore %JAVA%\lib\security\cacerts -file \path\to\your\cert
(Be sure than you are not overwritting anything and the password for -import param by default is changeit)
This is a bit of a super duper specific question, but who knows there's someone out there that can help me.
I happen to have Philips Hue Bridge and I would love to know what personal information it is sharing with the outside world. Using tcpdump on my router I figured the Hue Bridge has a rather talkative personality. But because it talks over SSL tunnels, I have no idea what it says. So what I did is I setup a SonicWall with SSL-DPI with a CA, got root access to the Hue Bridge and found the application that does the talking to wws://ws.meethue.com (its called websocketcd). I then replaced the root certificate on the Hue Bridge, adjusted the cipher to match the Sonicwall and now I am stuck due to boost.asio trowing an validation error of my certificate:
error:14090086:lib(20):func(144):reason(134)
For those not too familiar with the error codes, this is what they mean:
lib(20) is ERR_LIB_SSL
func(144) is SSL_F_SSL3_GET_SERVER_CERTIFICATE
reason(134) is SSL_R_CERTIFICATE_VERIFY_FAILED
To verify it's not my SonicWall or certificate that is causing the problem, I executed openssl s_client -connect ws.meethue.com:443 -CAfile ca.pem from the Hue Bridge and that validates the chain perfectly fine, the same way as the original certificate. I also verified that the application is loading my root certificate and cipher correctly (because if change the cipher, I get a cipher error error). Also in my browser, I can visit https://ws.meethue.com without certificate errors. Here's my self made certificate chain, in case someone wants to check it: https://gofile.io/d/5msjoJ (password for download/key 1020304050, it's a temporary key that only exists in my local test env. so it's safe to share ;-)
If websocketcd wasn't a binary file, the problem was super easy to solve using set_verify_mode, but unfortunately it is a binary and that makes life significantly more complicated.
Is there anyone who can give me advice how to make this blob called websocketcd with boost.asio in it accept my root certificate? What I tried too: letting it communicate without ssl and with ssl without encryption (eNULL:aNULL ciphers). I am a bit hesitant to share the blob but for those who have a Hue Bridge too, it's located at /usr/bin/websocketcd.
Perhaps you can use strace (or maybe even ltrace) to spot which certificate paths it is using for root authorities.
If it uses a single file, you might be abel to hack it by replacing it with a CA that verifies your MITM certificate.
Sometimes the file can contain multiple certificates, so worth appending/prepending yours.
If you're in luck, there will be a readdir on a directory containing certificates. If so, you should be able to add your root certificate (in PEM form) there and **remember to run c_rehash on that directory.
For those interested: after some 20hrs, I figured that websocketcd requires a certificate revocation list for each CA in the chain (which do not have to have any revoked serials). These CLRs need to be included in the root CA file that is loaded using the ca-filename argument. I was not aware that Boost Asio could demand that a CLR is present for each CA, but apparently, they (Signify) managed to do so.
I'm trying to download object store.
I'm getting below error while connecting to Anypoint Connectors Update Site - https://repository.mulesoft.org/connectors/releases/3.5.0
Unable to read repository at https://repository.mulesoft.org/connectors/releases/3.5.0/content.xml.
Unable to read repository at https://repository.mulesoft.org/connectors/releases/3.5.0/content.xml.
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
It seems you are facing some ssl certificate issues, this usually occurs when your JVM truststore contains self-signed certificates (i.e. certificates not signed by a CA).
This case occurs when Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to that application if it can trust it. The way trust is handled in the Java world is that you have a keystore (typically $JAVA_HOME/lib/security/cacerts), also known as the truststore. This contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CAs or public certificates that exist within that keystore.
But before jumping to conclusion do check Case 1 and 2
Case 1 : Check if the link is not blocked by your firewall
Do refer the Mulesoft Doc
Case 2 : Simply update your java (this is easy way)
Case 3 : Download Certificate manually and add in Java's truststore
Refer this link to know how to download certificate manually and this link to add the certificate to the truststore (you will need OpenSSL toolkit to transform the certificate to required format, it is described in the the mentioned link), and in case you are not familiar with different extension related to SSl certificate go check out this SO answer
My app connects to Worklight server through HTTPS through self-signed certificate. The app can be launched successfully.
However, when there is direct update which started downloading file from Worklight server, it is failed and I can see that there are error message regarding certification path not found.
May I know if the SSLHandshakeException and direct update error are correlated?
Thanks!
(Environment: Worklight 5.0.6.1, WAS ND 8.5, Testing Device: HTC One)
10-31 21:24:50.897: W/System.err(28746): Catch exception while startHandshake: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
10-31 21:24:50.897: W/System.err(28746): return an invalid session with invalid cipher suite of SSL_NULL_WITH_NULL_NULL
10-31 21:24:50.927: E/WLDroidGap(28746): Failed downloading application update file.
Yes, the use of direct update and the SSL handshake errors are related. Android doesn't allow you to work with self-signed certificates (unless you somehow bypass SSL). Because you can't install a self-signed cert into Android's truststore, the Android client can't establish trust for the server's self signed certificate.
You probably have the following flag specified in your Android manifest file:
android:debuggable="true"
This flag disables SSL validation when going thru the hybrid channels and probably the reason why you don't see the SSL errors earlier. Direct update is handled at a different level, where this flag does not apply, and therefore SSL validation does occur.
You should use self-signed CA certificates instead for dev/test purposes. See the following answer on how to generate a self-signed CA:
https://stackoverflow.com/a/19841469/2494287
Direct update will not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.