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.
