Modify

Opened 16 months ago

Closed 13 months ago

Last modified 2 weeks ago

#12264 closed enhancement (fixed)

Add own CA's to Java cert-store

Reported by: stoecker Owned by: team
Priority: major Milestone: 16.04
Component: Core Version:
Keywords: Cc: bastiK, Don-vip, lists@…

Description (last modified by 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

Attachments (3)

certificate-amendment.diff (6.9 KB) - added by bastiK 14 months ago.
certificate-amendment2.diff (10.0 KB) - added by bastiK 14 months ago.
CertificateAmendment.patch (2.5 KB) - added by wiktorn 13 months ago.
Corrected patch

Download all attachments as: .zip

Change History (77)

comment:1 Changed 16 months ago by stoecker

Description: modified (diff)

comment:2 Changed 16 months ago by 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.

comment:3 in reply to:  2 Changed 16 months ago by 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.

comment:4 Changed 16 months ago by Don-vip

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

comment:5 Changed 16 months ago by Aun Johnsen <lists@…>

Cc: lists@… added

comment:6 Changed 14 months ago by simon04

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

Changed 14 months ago by bastiK

Attachment: certificate-amendment.diff added

comment:7 Changed 14 months ago by bastiK

The attached patch should fix this problem.

comment:8 Changed 14 months ago by 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?

comment:9 Changed 14 months ago by 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?

comment:10 in reply to:  8 Changed 14 months ago by 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.

Last edited 14 months ago by bastiK (previous) (diff)

Changed 14 months ago by bastiK

Attachment: certificate-amendment2.diff added

comment:11 Changed 14 months ago by bastiK

Patch is updated with fixed paths and hash check.

comment:12 Changed 14 months ago by Don-vip

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

comment:13 Changed 14 months ago by stoecker

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

comment:15 Changed 14 months ago by 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.

Last edited 14 months ago by stoecker (previous) (diff)

comment:16 Changed 14 months ago by bastiK

Resolution: fixed
Status: newclosed

In 9995/josm:

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

comment:17 Changed 14 months ago by bastiK

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

comment:18 Changed 14 months ago by Klumbumbus

Milestone: 16.03

comment:19 Changed 14 months ago by Don-vip

Resolution: fixed
Status: closedreopened

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

comment:20 in reply to:  19 Changed 14 months ago by 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)

comment:21 Changed 14 months ago by 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)

comment:22 Changed 14 months ago by Don-vip

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

comment:23 Changed 14 months ago by bastiK

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

comment:24 Changed 14 months ago by 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.

Last edited 14 months ago by bastiK (previous) (diff)

comment:25 in reply to:  17 ; Changed 14 months ago by 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?

comment:26 in reply to:  25 Changed 14 months ago by 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

comment:27 Changed 14 months ago by 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"

comment:28 Changed 14 months ago by Don-vip

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

comment:29 in reply to:  27 Changed 14 months ago by 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?

comment:30 Changed 14 months ago by 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 :)

comment:31 Changed 14 months ago by bastiK

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

comment:32 Changed 14 months ago by 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?

comment:33 Changed 14 months ago by 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.

comment:34 in reply to:  32 Changed 14 months ago by 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.

comment:35 Changed 14 months ago by Don-vip

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

comment:36 Changed 14 months ago by 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)

comment:37 Changed 14 months ago by bastiK

Resolution: fixed
Status: reopenedclosed

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)

comment:38 Changed 13 months ago by wiktorn

In 10076/josm:

Better error reporting for hash mismatch.

See: #12264

comment:39 Changed 13 months ago by wiktorn

Resolution: fixed
Status: closedreopened

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

Last edited 13 months ago by wiktorn (previous) (diff)

comment:40 Changed 13 months ago by 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?

comment:41 Changed 13 months ago by stoecker

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

comment:42 Changed 13 months ago by stoecker

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

comment:43 Changed 13 months ago by 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.

Changed 13 months ago by wiktorn

Attachment: CertificateAmendment.patch added

Corrected patch

comment:44 in reply to:  43 Changed 13 months ago by 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.

comment:45 in reply to:  40 Changed 13 months ago by 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.

comment:46 Changed 13 months ago by 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.

comment:47 Changed 13 months ago by 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".

comment:48 Changed 13 months ago by wiktorn

Resolution: fixed
Status: reopenedclosed

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

comment:49 Changed 13 months ago by wiktorn

In 10085/josm:

Add Certum CA certificate used by GUGiK in Poland.

See: #12264

comment:50 Changed 13 months ago by stoecker

In 10088/josm:

see #12264 - revert r10085

comment:51 Changed 13 months ago by 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.

comment:52 Changed 13 months ago by wiktorn

Done in #12710

comment:53 Changed 13 months ago by Don-vip

Milestone: 16.0316.04

Milestone renamed

comment:54 Changed 12 months ago by Don-vip

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

comment:55 Changed 12 months ago by bastiK

What does it mean for us?

comment:56 Changed 12 months ago by 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?

comment:57 in reply to:  56 ; Changed 12 months ago by 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.

comment:58 in reply to:  56 Changed 12 months ago by 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

comment:59 in reply to:  57 ; Changed 12 months ago by 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.

comment:60 in reply to:  59 Changed 12 months ago by 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.

comment:61 Changed 12 months ago by bastiK

In 10156/josm:

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

comment:62 Changed 12 months ago by 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

comment:63 Changed 12 months ago by 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.

comment:64 Changed 12 months ago by bastiK

In 10157/josm:

see #12264 - add TLS test url with SNI

comment:65 Changed 11 months ago by Don-vip

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

comment:66 Changed 11 months ago by 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.

comment:68 Changed 11 months ago by Don-vip

In 10324/josm:

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

comment:69 Changed 9 months ago by 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.

comment:70 Changed 6 months ago by bastiK

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

comment:71 in reply to:  70 Changed 6 months ago by 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.

comment:72 Changed 6 months ago by 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.

comment:73 Changed 2 weeks ago by bastiK

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

comment:74 Changed 2 weeks ago by bastiK

see #14652 - Remove Let's Encrypt certificate

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.