Will the cross root cover trust by the default list in the JDK/JRE?

So, I guess I’m gonna have to do this again a few times so made a small script, might be useful for someone else:

You shouldn’t need to store (and probably shouldn’t store) the intermediate certs in the root trust store. Rather, add both the ISRG root and the DST root. All the certs made right now with the letsencrypt client use an intermediate chained back to the DST root because it has wider trust acceptance.

3 Likes

Since @pfg mention this topic as relevant for oracle jdk root inclusion.
It would be nice to get an update if there is any progress or timeline.

Getting LE-verified site e.g. https://gethttpsforfree.com/ fails for current latest Oracle java (1.8.0_91).

Oracle needs to add IdenTrust’s DST Root X3 to Java in order for things to work by default. I’ve been notified by Oracle that they have accepted the root into their program and that it will ship in a software update. I don’t know when that software update will ship, unfortunately.

3 Likes

Very good news!
Do you know at least if it will be in a major update (i.e. JRE 9) or in a minor update?

Thanks

1 Like

The ticket at https://bugs.openjdk.java.net/browse/JDK-8154757 and shows a backport for JDK 8u101. The next Oracle Critical Patch Update is July 2016 per http://www.oracle.com/technetwork/topics/security/alerts-086861.html

1 Like

Just wanted to let you know that importing chain.pem into cacerts (/etc/ssl/java/cacerts) from /etc/letsencrypt/live// worked with an Oracle JDK 1.8.0_91 in Debian 64. In my case I used the certificates for a Jira Tomcat container which had its own JDK by the way. So check carefully which JDK is really used.

Even though the certificate should’ve been added to Java per https://bugs.openjdk.java.net/browse/JDK-8154757, the latest JDK 8u112 Build b02 from Early Access Releases (https://jdk8.java.net/download.html) still doesn’t have it. Java trust store file (lib/security/cacerts) hasn’t changed since JDK 8u92.

I’ve just tried the latest Java 9 build and its cacerts also still doesn’t include IdenTrust and DST certificates. Any idea why?

:smile: Letsencrypt certificates are confirmed working with Oracle JDK >= 8u101 (release)

List of browsers and operating systems where LE is trusted ( Which browsers and operating systems support Let's Encrypt) updated.

2 Likes

Who confirmed that and how? I just tried to access a website whose certificate was issued by “Let’s Encrypt Authority X3” with jdk 8u102 and it did not work.

I used my h4x0r3d code https://gist.github.com/Firefishy/b2e606c42edcc4f513ba with JDK 8u101 and worked as expected. Java™ SE Runtime Environment (build 1.8.0_101-b13)

Works for me on OS X (10.12 beta 3 / jdk-8u102):

1 Like

Embarassing, I just THOUGHT I used the new JDK - thx :slight_smile:

1 Like

Is it safe to distribute chain.pem to my users?

chain.pem is a certificate which can be downloaded from https://letsencrypt.org/certificates/ … So yes, that would be safe. Only private keys should be kept private :wink:

By the way: webservers using Let’s Encrypt certificates should provide chain.pem in their TLS handshake, so it is distributed already most of the time.

Error still here.
$ java -version
openjdk version "1.8.0_102"
OpenJDK Runtime Environment (build 1.8.0_102-b14)
OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)

After copy /usr/local/linux-oracle-jdk1.8.0/jre/lib/security/cacerts to /usr/local/openjdk8/jre/lib/security/cacerts all work fine => OpenJDK have old cacerts without trust for letsencrypt.

I’m still getting the “ValidatorException: PKIX path building failed” error with both Oracle’s Java 1.8.0_112 and RedHat’s OpenJDK 1.8.0_111 on Windows 7. Importing lets-encrypt-x3-cross-signed.der resolves the problem, but this doesn’t seem to be sufficient for the OpenJDK 1.8.0_111 on Ubuntu 16.04…