Add own CA's to Java cert-store

[stoecker]

The fact that Oracle does not follow the CA handling of the web browsers and causes problems with renewal of the web-pages we access (josm.openstreetmap.org, svn.openstreetmap.org, wiki.openstretmap.org, trac.openstreetmap.org, taginfo.openstreetmap.org, (gps-)(a|b|c).tile.openstreetmap.org, www.openstreetmap.org, nominatim.openstreetmap.org, api.openstreetmap.org).

The test with StartSSL/Wosign showed that this is mainly a Windows issue, as (all?) the Linux versions use the systemwide certificate store (as well as WebStart?).

A solution for the future would be if we would add CA's ourself, which are commonly accepted (except by Oracle) and used by the sites we access. That could include StartSSL (+Wosign) and IdenTrust (+Let's Encrypt).

The idea would be to test whether certain CA's are acceptable (either the list is readable or we can setup test pages for these) and if not ask the user if the CA's should be installed. The result should be remembered, so this is only asked and done once.

This methods should be limited to certs which are accepted by the big three browsers (Firefox, Chrome and IE).

See

• ​https://github.com/openstreetmap/operations/issues/2
• ​https://github.com/openstreetmap/operations/issues/55
• #12192
• ​https://lists.openstreetmap.org/pipermail/josm-dev/2015-December/007560.html
• ​https://lists.openstreetmap.org/pipermail/josm-dev/2015-December/007564.html (thread)

[Don-vip]

Not only Windows but OSX as well. I see no problem with josm website myself: the procedure with GlobalSign is straightforward enough, I still don't see why StartSSL would be a better choice.

For Let's Encrypt we can handle the root CA ourselves if it's not added in 8u72 (19th January), until Oracle adds it.

[stoecker]

Replying to Don-vip:

Not only Windows but OSX as well. I see no problem with josm website myself: the procedure with GlobalSign is straightforward enough, I still don't see why StartSSL would be a better choice.

StartSSL because that's the established free certificate. Whether we use this for JOSM page or not is independent from this. We also access pages containing styles and presets and so on. And as we encourage HTTPS, we should support the free ones.

For Let's Encrypt we can handle the root CA ourselves if it's not added in 8u72 (19th January), until Oracle adds it.

No. Let's Encrypt itself is out of question. That's much too new and the rule should be that we only add certificates which are accepted by the big browsers. So until it is really established (which will take much more time, at least a year) we can only support IdenTrust which is established.

I don't want that we start our own rules. Either we follow the bigger players or we don't do it at all.

[Don-vip]

Yes I meant IdenTrust. This one exactly: ​https://ssl-tools.net/certificates/cv0tp9-dst-root-ca-x3

[simon04]

See #12612: an imagery server switched from HTTP to HTTPS only and uses a Let's Encrypt certificate.

[bastiK]

The attached patch should fix this problem.

[Don-vip]

is there a way to accept custom certificates without updating the JRE cacerts? By doing something purely in memory? This approach needs root privileges, no?

[stoecker]

We should also add a CRC/SHA verification of the certs file and not allow to change the path to the certs file, but hardcode the resource. It should only be possible to load that one file, nothing else.

@Vincent: Root privileges or is this stored user related?

[bastiK]

Replying to Don-vip:

is there a way to accept custom certificates without updating the JRE cacerts? By doing something purely in memory? This approach needs root privileges, no?

This is done in memory - it never writes to the file system.

Replying to stoecker:

We should also add a CRC/SHA verification of the certs file and not allow to change the path to the certs file, but hardcode the resource. It should only be possible to load that one file, nothing else.

Yes, sounds reasonable. I would appreciate some help to find the CA's we need to add + test URL.

[bastiK]

Patch is updated with fixed paths and hash check.

[Don-vip]

nice :) what we should add now is a unit test that connects to ​https://letsencrypt.org/ (and other CA websites if needed)

[stoecker]

Add StartSSL as well. Together with Let's Encrypt these are the two relevant free CA certs nowadays.

[stoecker]

That one is in Firefox and also the one which I'm using everywhere (256 bit self-signed): ​https://ssl-tools.net/certificates/a3f1333fe242bfcfc5d14e8f394298406810d1a0.pem (​https://ssl-tools.net/subjects/4173a6d3d8df6acd191e896be7e5623930706935).

[stoecker]

Test URL: TLS of OpenStreetMap (Sorbian Language). The URL dstoecker.eu still uses StartSSL directly, the others use Wosign (a reseller). Wosign is also in Firefox, but probably adding StartSSL for now is ok. We should not add too many.

The cert-chains of above Wosign'ed URL's include StartSSL, so that the chain is complete even when only StartSSL is added.

P.S. We could also add the "G2" root cert, but I see no advantage for that, only disadvantages in case of shortened cert-chains on server side.

[bastiK]

In 9995/josm:

fixed #12264 - Add own CA's to Java cert-store

[bastiK]

@Dirk: You should check your perl scripts for regexes with 4 digit commit number. ;-)

[Don-vip]

It works with java7 but not with java8: jenkins/job/JOSM/jdk=JDK8/lastCompletedBuild/testReport/

[bastiK]

Replying to Don-vip:

It works with java7 but not with java8: jenkins/job/JOSM/jdk=JDK8/lastCompletedBuild/testReport/

What version? I've tested it with Oracle Java 8:

java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

[Don-vip]

Same one:

/var/lib/jenkins/tools/hudson.model.JDK/JDK8/bin/java -version

java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

[Don-vip]

have you tried to run unit tests manually ? To see if the problem comes from unit test itself or Jenkins environment.

[bastiK]

I ran the test manually on the server using that version of java with no error. Not sure what the problem is here.

[bastiK]

JAVA_HOME environment variable looks suspicious - should be /var/lib/jenkins/tools/hudson.model.JDK/JDK8/jre. Nevertheless, I would expect some kind of exception if the path is wrong.
Edit: There is nothing wrong with pointing JAVA_HOME to the jdk directory. Also it doesn't seem to change the java.home system property.

[stoecker]

Replying to bastiK:

@Dirk: You should check your perl scripts for regexes with 4 digit commit number. ;-)

Next issue should be 15000, not 10000 - I did think a little in advance after the last issue (8000?) - but who knows, the server code got large over the time. BTW, that was Python, not Perl. Do we make a 5th digit party?

[Don-vip]

Replying to stoecker:

Do we make a 5th digit party?

This year we can celebrate:

• the 10.000th commit
• the 10 years of JOSM 1.0 (22 january 2006)

I was thinking about a blog post on osm.org, something like "JOSM in numbers", with extracts from SonarQube JOSM history:
sonar/overview

[Don-vip]

@bastiK: some questions:

• TrustManagerFactory.getDefaultAlgorithm() => what happens for other algorithms? This returns "PKIX" on my system
• SSLContext.getInstance("TLS") ==> what about other values? javadoc lists "TLS", "TLSv1", "TLSv1.1" and "TLSv1.2"

[Don-vip]

what was the issue with 8000 btw? I don't remember

[bastiK]

Replying to Don-vip:

@bastiK: some questions:

Thanks for the review!

• TrustManagerFactory.getDefaultAlgorithm() => what happens for other algorithms? This returns "PKIX" on my system

There are no other algorithms as far as I'm aware (see ​doc (java 7) and ​doc (java 8)). PKIX validates the certificate chain according to the relevant internet standard. Even if there were alternatives, we should stick to the algorithm that is currently active, which would normally be the default one.

• SSLContext.getInstance("TLS") ==> what about other values? javadoc lists "TLS", "TLSv1", "TLSv1.1" and "TLSv1.2"

Right, the following code prints the activated protocols:

SSLContext sslContext = SSLContext.getDefault();
SSLSocket s = (SSLSocket) sslContext.getSocketFactory().createSocket();
String[] protocols = s.getEnabledProtocols();
System.err.println(Arrays.toString(protocols));

On Java 7 I get "[TLSv1]" and on Java 8 I get "[TLSv1, TLSv1.1, TLSv1.2]" (both Oracle and openjdk). This is as stated in the documentation.

Now using "TLS" in SSLContext.getInstance("TLS") happens to leave this unchanged. It is not obvious from the javadoc, ​this post gives some details.
If I change it to SSLContext.getInstance("TLSv1.2"), this activates TLSv1.1 and TLSv1.2 for Java 7 also.

I could include a check in the unit test, but it would require that CertificateAmendment.addMissingCertificates() has not been called before e.g. by gui Fixture from another test. Is this possible?

[Don-vip]

Found it: it's a conflict with the code I wrote long ago in the course of #10033, see RemoteControlHttpsServer.initialize():

    /**
     * Initializes the TLS basics.
     * @throws IOException if an I/O error occurs
     * @throws GeneralSecurityException if a security error occurs
     */
    private void initialize() throws IOException, GeneralSecurityException {
        KeyStore ks = loadJosmKeystore();

        KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
        kmf.init(ks, KEYENTRY_PASSWORD.get().toCharArray());

        TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
        tmf.init(ks);

        sslContext = SSLContext.getInstance("TLS");
        sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

        if (Main.isTraceEnabled()) {
            Main.trace("SSL Context protocol: " + sslContext.getProtocol());
            Main.trace("SSL Context provider: " + sslContext.getProvider());
        }

        setupPlatform(ks);
    }

The two pieces of code must be merged as they're conflicting each other :)

[bastiK]

In what way is the code conflicting and how can I reproduce?

[Don-vip]

I assume SSLContext.getInstance("TLS") returns a singleton instance, and we're both initializing it with a different keystore. So the second call override the first one. Am I wrong?

[Don-vip]

To reproduce, try to run a JUnit test suite that contains RemoteControlTest and CertificateAmendmentTest (order might be important), it should trigger the conflict.

[bastiK]

Replying to Don-vip:

I assume SSLContext.getInstance("TLS") returns a singleton instance, and we're both initializing it with a different keystore. So the second call override the first one. Am I wrong?

Javadoc states that a new object is returned, so it is more like a factory.
Replying to Don-vip:

To reproduce, try to run a JUnit test suite that contains RemoteControlTest and CertificateAmendmentTest (order might be important), it should trigger the conflict.

Nope, I only see the effect of RemoteControlTest.disableCertificateValidation, which makes also the self-signed cert pass in the test.

[Don-vip]

Damned. Need to look more into it, that's really strange.

[bastiK]

Running any test with

    @BeforeClass
    public static void setUpBeforeClass() {
        JOSMFixture.createUnitTestFixture().init(true);
    }

before will trigger the problem.
In fact running such a test alone will cause an exception (which is ignored and not counted as test failure):

Testsuite: org.openstreetmap.josm.gui.layer.geoimage.GeoImageLayerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.21 sec
------------- Standard Output ---------------
INFO: GET http://api06.dev.openstreetmap.org/api/capabilities -> 200 (369 B)
INFO: OK
INFO: GET https://josm.openstreetmap.de/maps -> !!!
------------- ---------------- ---------------
------------- Standard Error -----------------
WARNING: java.net.SocketTimeoutException: Read timed out
java.net.SocketTimeoutException: Read timed out
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
	at java.net.SocketInputStream.read(SocketInputStream.java:170)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	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:973)
	at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930)
	at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:135)
	at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:80)
	at org.openstreetmap.josm.io.CachedFile.checkLocal(CachedFile.java:467)
	at org.openstreetmap.josm.io.CachedFile.getFile(CachedFile.java:265)
	at org.openstreetmap.josm.io.CachedFile.getInputStream(CachedFile.java:200)
	at org.openstreetmap.josm.io.CachedFile.getContentReader(CachedFile.java:243)
	at org.openstreetmap.josm.io.imagery.ImageryReader.parse(ImageryReader.java:68)
	at org.openstreetmap.josm.data.imagery.ImageryLayerInfo$DefaultEntryLoader.loadSource(ImageryLayerInfo.java:154)
	at org.openstreetmap.josm.data.imagery.ImageryLayerInfo$DefaultEntryLoader.realRun(ImageryLayerInfo.java:136)
	at org.openstreetmap.josm.data.imagery.ImageryLayerInfo.loadDefaults(ImageryLayerInfo.java:100)
	at org.openstreetmap.josm.data.imagery.ImageryLayerInfo.load(ImageryLayerInfo.java:83)
	at org.openstreetmap.josm.gui.preferences.imagery.ImageryPreference.initialize(ImageryPreference.java:948)
	at org.openstreetmap.josm.Main$7.initialize(Main.java:631)
	at org.openstreetmap.josm.Main$InitializationTask.call(Main.java:720)
	at org.openstreetmap.josm.Main$InitializationTask.call(Main.java:704)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
ERROR: java.net.SocketTimeoutException: Read timed out
doing nothing...
------------- ---------------- ---------------

Testcase: testLoader took 0.002 sec

(with Oracle Java 8)

[bastiK]

In 10019/josm:

fixed #12264 - repair unit test

adding certificates must happen before the first TLS connection is made
(don't know why, but so be it)

[wiktorn]

In 10076/josm:

Better error reporting for hash mismatch.

See: #12264

[wiktorn]

I just tried to run the JOSM and I get failure:

java.lang.RuntimeException: certificate hash mismatch for resource://data/security/DST_Root_CA_X3.pem. Expected 139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99, was 794232094228a8377fff9da0ca5984e80cdb12366f84473a65a6741da725cdee

(using just committed extended reporting). And JOSM fails to start (though it leaves hanging process).

I'm using:

java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

on Windows.

I'm not sure if it's wise, to interrupt the startup procedure and refuse to start JOSM in such case.

Interesting is, that I get this error only with my custom builds, not with JOSM run with Java Web Start

[wiktorn]

Ok, I've nailed it down. When I build the jar file on Windows, the data/security/* files get Windows line endings, that's why this checks are failing.

Can we do the test, that cert.getSignature() matches some predefined value instead of this check? Shouldn't this be enough?

[stoecker]

As long as it checks that we load the correct cert it's fine.

[stoecker]

Why don't you simple hash the signature? That wouldn't change that much.

[stoecker]

Or there is probably an export function of the whole cert which can be hashed, or there is a fingerprint output. The idea of that second step is to have one indepent check. Embedding the cert into the code would not give that result.

[wiktorn]

Corrected patch

[wiktorn]

Replying to stoecker:

Or there is probably an export function of the whole cert which can be hashed, or there is a fingerprint output. The idea of that second step is to have one indepent check. Embedding the cert into the code would not give that result.

As I can agree, that it's good to verify, what Java is providing us, when we're getting the file from "somewhere", I don't understand the second check, when we are inlining certificate. It's either correct one, or not.

Regardless of the above - there is still outstanding case - what to do, if these checks fail. Should we abort, or shall we just warn the user, and continue starting. Right now, it somehow hangs.

[bastiK]

Replying to wiktorn:

Ok, I've nailed it down. When I build the jar file on Windows, the data/security/* files get Windows line endings, that's why this checks are failing.

How come? This shouldn't happen.

I'm not sure if it's wise, to interrupt the startup procedure and refuse to start JOSM in such case.

It indicates that the build is broken or has been tampered with. As no user should ever get this message, it doesn't matter really.

Can we do the test, that cert.getSignature() matches some predefined value instead of this check? Shouldn't this be enough?

Regarding the patch, I don't see why the change is necessary, but it is more or less the same.

[stoecker]

Two checks make it harder to exchange the certificates in the released binaries. It's not ultimate, but this way you need to exchange the files, trick the signing and also adapt the code.

[stoecker]

I think the patch is fine - this way the fingerprint also matches values from other tools like "openssl x509 -in DST_Root_CA_X3.pem -fingerprint -sha256".

[wiktorn]

In 10083/josm:

Check for certificate SHA-2 fingerprint instead of SHA-2 of PEM file.

Fixes problems due to different line endings on different systems / builds on Windows

Closes: #12264

[wiktorn]

In 10085/josm:

Add Certum CA certificate used by GUGiK in Poland.

See: #12264

[stoecker]

In 10088/josm:

see #12264 - revert r10085

[stoecker]

Sorry for the harsh reaction, but certificates are a sensitive topic. If we add something the minimum rules are:

• present a reason why
• show the usage status of the certificate in browsers
• present a link to the certificate (using ssl-tools.net)
• wait for discussion and a common decision of at least the three main admins

Usually do that in a new ticket.

[wiktorn]

Done in #12710

[Don-vip]

Milestone renamed

[Don-vip]

CertificateAmendmentTest.testLetsEncrypt is failing since today. It seem related to ​this comment

[bastiK]

What does it mean for us?

[Don-vip]

I think the test was wrong, we were testing DST root twice instead of testing ISRG then DST. They changed it so now the test fails until Oracle or ourselves add the ISRG root. As Dirk is opposed to this for now, we should change the test to false?

[stoecker]

Replying to Don-vip:

I think the test was wrong, we were testing DST root twice instead of testing ISRG then DST. They changed it so now the test fails until Oracle or ourselves add the ISRG root. As Dirk is opposed to this for now, we should change the test to false?

Please explain the situation. I don't understand it ATM.

[bastiK]

I can reproduce that helloworld.letsencrypt.org test is failing in JOSM, but letsencrypt.org works. But I don't see a difference with the openssl tool:

$ openssl s_client -connect letsencrypt.org:443
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = IdenTrust, CN = IdenTrust Commercial Root CA 1
verify return:1
depth=1 C = US, O = IdenTrust, OU = TrustID Server, CN = TrustID Server CA A52
verify return:1
depth=0 CN = letsencrypt.org, O = INTERNET SECURITY RESEARCH GROUP, L = Mountain View, ST = California, C = US
verify return:1
---
Certificate chain
 0 s:/CN=letsencrypt.org/O=INTERNET SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
   i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
 1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
   i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
 2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

$ openssl s_client -connect helloworld.letsencrypt.org:443
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = IdenTrust, CN = IdenTrust Commercial Root CA 1
verify return:1
depth=1 C = US, O = IdenTrust, OU = TrustID Server, CN = TrustID Server CA A52
verify return:1
depth=0 CN = letsencrypt.org, O = INTERNET SECURITY RESEARCH GROUP, L = Mountain View, ST = California, C = US
verify return:1
---
Certificate chain
 0 s:/CN=letsencrypt.org/O=INTERNET SECURITY RESEARCH GROUP/L=Mountain View/ST=California/C=US
   i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
 1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
   i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
 2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

[Don-vip]

Replying to stoecker:

Please explain the situation. I don't understand it ATM.

I'm not sure neither, but I think that helloworld.letsencrypt.org was using DST root instead of ISRG until someone complains about it on Mozilla forum (it appears there was no public website on *.letencrypt.org signed with the ISRG root).

If that's correct I don't understand why our test says that we were testing ISRG root.

Regarding openssl I don't understand neither: with Chrome it's absolutely clear that helloworld uses ISRG root => security warning because not yet trusted by Chrome.

[bastiK]

Replying to Don-vip:

Replying to stoecker:

Please explain the situation. I don't understand it ATM.

I'm not sure neither, but I think that helloworld.letsencrypt.org was using DST root instead of ISRG until someone complains about it on Mozilla forum (it appears there was no public website on *.letencrypt.org signed with the ISRG root).

If that's correct I don't understand why our test says that we were testing ISRG root.

Basically I copied it from ​here. (Maybe it had ISRG root some time in the past.)

Regarding openssl I don't understand neither: with Chrome it's absolutely clear that helloworld uses ISRG root => security warning because not yet trusted by Chrome.

Can confirm with websites that analyze certificate chains. The only explanation I can come up with, is that openssl connects differently in some way (like user agent) which causes the server to deliver a different certificate to the client. Anyway, I don't think this should concern us, as Java connection apparently gets the ISRG root.

[bastiK]

In 10156/josm:

see #12264 - helloworld.letsencrypt.org now using ISRG root - update test

[stoecker]

Hah, I can answer the openssl problem. Some days ago I had a similar issue. The tool openssl does not use SNI by default, so you get another certificate chain and not the expected one.

Try

openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org

[bastiK]

That's it!

$ openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/CN=helloworld.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1

Now I recall this is the reason why I didn't question the duplicate entry: One requires SNI and the other doesn't.

[bastiK]

In 10157/josm:

see #12264 - add TLS test url with SNI

[Don-vip]

Oracle has finally added IdenTrust root: see ​javabug:8154757. It will be available in next Java update (8u101 scheduled in July 2016).

[Don-vip]

They have just switched back ​https://helloworld.letsencrypt.org/ from ISRG to DST root, making our unit test fail :( I have no idea why.

[Don-vip]

more info here: ​https://community.letsencrypt.org/t/helloworld-letsencrypt-org-certificate-expires-this-weekend/16197

[Don-vip]

In 10324/josm:

see #12264 - disable ​https://helloworld.letsencrypt.org test until the situation is clarified

[Don-vip]

JDK8u101/102 is finally released and contains IdenTrust certificates:
​http://www.oracle.com/technetwork/java/javase/8u101-relnotes-3021761.html
​http://www.oracle.com/technetwork/java/javase/8u102-relnotes-3021767.html

New IdenTrust certificates added to root CAs
Three new root certificates have been added:

IdenTrust Public Sector Root CA 1
alias: identrustpublicca
DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US

IdenTrust Commercial Root CA 1
alias: identrustcommercial
DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US

IdenTrust DST Root CA X3
alias: identrustdstx3
DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
See ​JDK-8154757

So when this version will be used enough we will be able to remove the embedded certificate.

[bastiK]

Mozilla is ​revoking its trust in WoSign/StartSSL CA because of - as they put it - a number of technical and management failures.

[stoecker]

Replying to bastiK:

Mozilla is ​revoking its trust in WoSign/StartSSL CA because of - as they put it - a number of technical and management failures.

While I fully agree with that step in case of Wosign, for StartSSL that still feels somewhat strange to me. Mozilla is shutting down the only competition in free certificates it has, but other failures of commercial issuers are hardly ever sanctioned. The fact that Mozilla itself is operating a CA does not help me to trust their decisions fully.

Anyway we need to react as well - Let's see what the next weeks will bring.

[bastiK]

StartSSL is now owned 100% by WoSign. It is presumed, the WoSign software stack and infrastructure has been rolled out for StartSSL, since their certificates now show the same quirks as the ones from WoSign.

[bastiK]

In [11903]: drop StartCom as Chrome does no longer trust it even for older certs

[bastiK]

see #14652 - Remove Let's Encrypt certificate

[Don-vip]

Ticket #12739 has been marked as a duplicate of this ticket.