Thanks for offering this fix. I just spent $15 and half an hour to make the problem go away for three years, so I’m not really in a position to test it now.
I see my own reply up above here, but suddenly I have the issue again:
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/content/groups/All/se/hedefalk/lift-utils_2.5_2.11/0.1/lift-utils_2.5_2.11-0.1.pom
Even though I follow my own instructions above of importing isrgrootx1 and letsencryptauthorityx1, the problem persists. The only thing I can think of is that I have gone to using SAN extensions for all my subdomains in one cert. Or that the root cert has changed?
Oh, it’s the later:
The X1 and X2 intermediates were our first generation of intermediates. We’ve replaced them with new intermediates that are more compatible with Windows XP.
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.
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.
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?
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
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?
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.
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):
Embarassing, I just THOUGHT I used the new JDK - thx
Is it safe to distribute chain.pem to my users?