I have been surprised to observe that the code ClientBuilder.newBuilder().connectTimeout(10, TimeUnit.SECONDS).readTimeout(10, TimeUnit.SECONDS).build().target("https://www.oracle.com/java/technologies/naming-conventions.html").request().get(); throws a “Read timed out” exception using the Jersey JAX-RS client implementation. (When I tried to report this, I was told that it is not a bug.)
I expected that Jersey would use the default Java truststore, and that the default Java truststore would include CA certificates that permit to trust Oracle’s (and many other) website.
Indeed, running keytool -list -cacerts, I see that my truststore contains 166 certificates. I suppose that some of them permit to validate Oracle’s website, but I do not know how I can check that (well, apart from doing exactly what I am trying to do with Jersey).
I realize that I can download Oracle’s certificate and add it to my truststore, but I obviously do not want to do this for every classical web site out there to which I would like to connect using SSL. I would rather like to understand which web sites are supposed to be trusted by default in a “normal” Java installation (is there an official documentation about this somewhere?); how I can check whether my specific installation has some problem that prevents Oracle’s web site to be trusted; or, if it is normal, whether I can tell Java once and for all to trust the web sites that, say, Firefox or Chromium would trust by default.
This answer, for example, suggests that OpenJdk (which is what I use) should trust by default the same web sites as Firefox. And Firefox obviously trusts Oracle.
What am I missing?
Edit I realize it seems relevant to specify that I use Debian stable, as this issue might be OS-specific. I wonder if there’s something going wrong on my installation. “As far as I'm aware every distro patches OpenJDK to use its own list, which I guess is why this issue hasn't got much attention on GNU/Linux systems” -- Andrew Haley on OpenJDK ML. “Debian has tooling to create a cacert file from the system‘s keystore. There is a hook system that updates the cacert every time the system‘s keystore is changed. lib/security/cacert is actually a symlink to that file. (…) In case of Debian, it‘s identical with Mozilla‘s list.” -- aahlenst on GH Adoptium issue. Indeed: ls -l /usr/lib/jvm/default-java/lib/security/cacerts reveals that it links to
/etc/ssl/certs/java/cacerts.
Related
For my personal pet-project I wrote on Java application, which pulls code from GIT repository through https and performs some analysis. However when I started testing it against code store in corporate repository I got “PKIX path building failed” and “unable to find valid certification path to requested target” errors.
Quick googling showed that the main cause of the problem is incorrect SSL settings in the infrastructure like self-signed certificate, for example.
I found possible workarounds to avoid this error:
Add host certificate manually into JRE trusted certificates.
Dynamically add the certificate to trusted certificates from applications resource files during its startup.
During startup of the app disable SSL validations at all, but this makes application vulnerable to "man in the middle" attacks.
But that's not the question.
When I was working with this corporate repository with standard GIT client (through https too) I've never got any issues with SSL or certificates. So the question is - how does official GIT client avoids this problem with self signed certificate in the chain?
Git itself does not do anything with any of this.
Git uses helpers—external programs and libraries—when talking to other Git providers. Those programs and libraries are responsible for all of this. So if you use git fetch or git push—note that git pull uses git fetch—and you use these with a URL that begins with https://, Git uses a system-provided HTTPS library,1 usually called "libcurl" or just curl. If you use an ssh:// URL, Git uses the system-provided ssh.
The Pro Git Book includes a chapter on Git Internals, with one section dedicated to Environment Variables. When using libcurl, these variables are particularly useful:
GIT_CURL_VERBOSE prints out the same stuff that curl -v prints.
GIT_SSL_NO_VERIFY turns off SSL certificate verification. So the default must be to do that verification, which (of course) will have issues with self-signed certificates.
When I was working with this corporate repository with standard GIT client (through https too) I've never got any issues with SSL or certificates.
That's interesting and curious; perhaps invoking Git with GIT_CURL_VERBOSE set will show what's going on here, or perhaps not. Or, perhaps the libcurl that was used to build your particular Git uses some CA files that your Java libraries do not.
1The details for this will depend on how your Git binaries were built. If you like, you can get the source code for Git and build it yourself, and thus have control over which library is used.
We are upgrading to Oracle Forms 11gR2. After the upgrade when I open my application in Development its giving me the security warning:
"Do you want to Run this application". Publisher : Unknown.
I explored and found we have to get a signed Certificate from CA (which I believe will cost money). I tried a self-signed certificate but still it's showing the warning message. Can anybody share the steps to get and import self-signed certificate for my Application?
I know only the Development URL and having admin rights. I don't have any source code for JAR.
Java checks from a certain version (I think 1.7 u21) if everything it needs to run that is not local is secure. This mean it needs a valid certificate and not a self signed version.
If however you still want to run your java applet without the signing or a self signed version you can make exceptions in the java control panel in the security tab, there you've got a button edit site list...
If you add here the url you start fe: http://localhost:8888/forms/frmservlet?config=webutil then you can start the forms. You still need to say everything is ok to run it and not block it. But it will work.
If you're using self-signed certificate, then you can import the certificate to java and that would solve the issue.
another way is to change the java.policy file.
I have a jar-file which is code signed. When I try to start the application with Java Web Start I get a warning that the Permissions attibute is missing in the manifest.
I removed the *RSA and *SH files from the META-INF folder and added the following attributes to the manifest:
Permissions: all-permissions
Codebase: *
Application-Name: application
Then I signed the jar-file using the jarsigner. When I try to start the application I get a error message that the application is blocked, because of security settings. After changing the security settings to medium I can start the application, but the publisher is unknown.
What can I do, so that the publisher is not unkown?
The complete answer to this topic would be concerning the new security restrictions for Java (so, depending on your version, and in this case of a webstarted app,also the client's version).
See this link as a starting point.
Anyway, from what you describe, and ask, there are basically two ways so that the publisher "is not unknown".
a) Use a "trusted issuer". This means, acquiring a code signing certificate from a known (to Java) Certification Authority.
This also means, in many cases, buying it from them (you could explore some dev options not for production use).
When you own a certificate like that, you repeat the signature process, and if you choose a CA Java has on-board (ex: Thawte, Symantec/Verisign,etc), you,as the signer, will be "known".
b) As I understand, you are using a self-signed certificate.
In this case (a little cumbersome and unsafe ) you could install you self-signing CA certificate into the executing JRE trust store (keystore). For this you should use the keytool java tool and have a little experience with PKI jargon.
The biggest drawback of this approach is that this requires an action on the client platform (writing files,etc), even if one-shot, this is not feasible usually (unless manageable/restriced area, such as intranets)
After a server change, I get nasty SSL warning in browsers (tested FF & Chrome), when loading an applet, used in an JavaEE Application (Serlvet API 3)
The warning says: "Certificate is not valid, and cannot used to identify the website"
The more detailed warning says: "The certificate authority, who provided the certificate, is not trusted." The messages are translated into english, so please excuse slight differences there. After this message, I get the message of Java, which shows that the Applet is ordinary signed (the dialog with the blue sign). So the Applet is working, only the warning message annoys.
Before I moved to another server, everything was fine and worked. No security warnings or anything else. The Applet is signed, by a certificate, which I requested from an CA. (rapidssl)
The old server environment was just a common web space, offered by 3rd party hoster. Now I moved to my own server, which utilizes XEN for hosting VMs. On one of that internal vm's, our webserver is deployed. According to that, I defined firewall rules to route traffic http/https to the vms.
Also the domain was ported, was purchased at old hoster, and the ip of new server is bound to domain.
I use Tomcat 7 as Application Server on an debian based OS.
In old environment, I could use the specified url in CN of my wildcard cert.(e.g. *.domain.com)
In new environment the basic message says: *.domain.com:port is not a trusted site.
I thought actually, that SSL Certs are independent of the used port. I've read that, on some research too. I also searched here in many threads, but the supposed answers didnt work for me.
The certificate and root cert. are imported to Java's own keystore cacerts. In Tomcat 7, I use the JSSE Implementation for SSL, with properly setup keystore files.
I've tried already this, but as im not that experienced with SSL/TLS Technology, the tried solutions maybe even wont solve my problem:
Disabling SNI in Tomcat 7 (dont work)
Adding Host aliases in server.xml (dont work)
Can anyone clarify, what the actual problem is, or has experienced the same issue ?
#edit: The are no error stacktraces in any logs, which I could provide here, also no exceptions gets thrown.
It came clear, thanks to Khanna111 Gaurav Khanna and jwv, that the certificate chain wasnt setup properly. I thought, if there were any problems with the certificate chain, that the browser will notify me about it. It isn't like that.
As we migrated from old hoster to new server, they provided only the certificates, but without the private key.
As im not that much experinced with SSL, I thought that importing the intermediary certs and the acquired cert is enough.. It is not :)
After stumbling on
intermediate-ca-certificate-in-java (link in comment), I've read this, which solved my problem: why doesn't java send the client certificate during SSL handshake? & external website:Import private key and certificate into Java Key Store (JKS)
I had certkey.key,publiccert.crt, intermediate_primary.cer and secondary_primary.cer Files.
The first step was, to convert the .key and .crt file to DER format, as mentioned in last link
via OpenSSL due to keytool's inability to import a key in an existing keystore
After converting to DER Format, I used the Tool ImportKey and created a new keystore with key/cert contained.
The second step was following the instructions of second link (Bruno's Answer), so it was copy&paste the certificate contents, into a single file. After importing the bundle of certificates into keystore, everything was fine.
I hope this can help anyone else, which is also not that familiar with SSL.
p.s. due to my lack of rep, i cannot mention all sites, I've used.. I'll provide them in comments
I have a Java web app that has been running fine for several months. It integrates with the Box API (https://upload.box.com/api/2.0) to save files to the cloud service. Out of the blue, we started receiving the dreaded javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated exception while trying to make a REST API call to the Box web service.
There are tons of posts out there that tell you how to manually import the cert into your key store using the keytool utility. I understand that I can do this to fix the problem. But is this really the correct fix?
The fact that my application has been running fine for months leads me to believe something in the certificate at https://upload.box.com changed. Looking at the cert in my web browser, the certificate seems valid and was only renewed a few weeks ago. What is missing from my keystore?
Is it the Root CA certificate that is missing from my keystore? If that is the case, could I just copy the cacerts file from newer version of Java? My app is currently running JDK 1.6.0_33.
I am just trying to understand why this would suddenly stop working and what the "real" fix should be. It doesn't seem like modifying the JDK keystore is the correct thing to do.
I'll just assume you're using Apache HTTP Client 4.x, before 4.2.6, 4.3 Beta2, in which case javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated is most likely to come from a certificate that isn't trusted (otherwise it means the server didn't send a cert, which is a different problem, more details in this answer).
The current cert for server you're trying to access seems to have been issued on 07/04/2014, so this indicates that the certificate, and perhaps its chain has changed recently indeed.
I don't have a JDK 1.6.0_33 at hand, but it's possible that some of these CA certs were not part of the default bundle. In any case, it's worth updating cacerts, even on older JREs (if only to remove CA certs that should no longer be trusted, for example). The JSSE Reference Guide clearly states (admittedly in the middle of a fairly long document, but it's worth searching for "important note"...):
IMPORTANT NOTE: The JDK ships with a limited number of trusted root certificates in the <java-home>/lib/security/cacerts file. As documented in keytool, it is your responsibility to maintain (that is, add/remove) the certificates contained in this file if you use this file as a truststore.
Depending on the certificate configuration of the servers you contact, you may need to add additional root certificate(s). Obtain the needed specific root certificate(s) from the appropriate vendor.
If you can't upgrade your JRE (Java 6 is in general out of support), updating the cacerts file from a more recent version is certainly a sensible compromise.
Besides the various fixes in Java 7, Java 7+ would also allow you to connect to hosts that require SNI (although this doesn't seem to be the case for this particular host).