Modify

Opened 8 years ago

Closed 8 years ago

Last modified 6 years 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 8 years ago.
certificate-amendment2.diff (10.0 KB ) - added by bastiK 8 years ago.
CertificateAmendment.patch (2.5 KB ) - added by wiktorn 8 years ago.
Corrected patch

Download all attachments as: .zip

Change History (78)

comment:1 by stoecker, 8 years ago

Description: modified (diff)

comment:2 by Don-vip, 8 years ago

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.

in reply to:  2 comment:3 by stoecker, 8 years ago

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 by Don-vip, 8 years ago

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

comment:5 by Aun Johnsen <lists@…>, 8 years ago

Cc: lists@… added

comment:6 by simon04, 8 years ago

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

by bastiK, 8 years ago

Attachment: certificate-amendment.diff added

comment:7 by bastiK, 8 years ago

The attached patch should fix this problem.

comment:8 by Don-vip, 8 years ago

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 by stoecker, 8 years ago

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?

in reply to:  8 comment:10 by bastiK, 8 years ago

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 8 years ago by bastiK (previous) (diff)

by bastiK, 8 years ago

Attachment: certificate-amendment2.diff added

comment:11 by bastiK, 8 years ago

Patch is updated with fixed paths and hash check.

comment:12 by Don-vip, 8 years ago

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

comment:13 by stoecker, 8 years ago

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

comment:15 by stoecker, 8 years ago

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 8 years ago by stoecker (previous) (diff)

comment:16 by bastiK, 8 years ago

Resolution: fixed
Status: newclosed

In 9995/josm:

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

comment:17 by bastiK, 8 years ago

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

comment:18 by Klumbumbus, 8 years ago

Milestone: 16.03

comment:19 by Don-vip, 8 years ago

Resolution: fixed
Status: closedreopened

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

in reply to:  19 comment:20 by bastiK, 8 years ago

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 by Don-vip, 8 years ago

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 by Don-vip, 8 years ago

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

comment:23 by bastiK, 8 years ago

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 by bastiK, 8 years ago

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 8 years ago by bastiK (previous) (diff)

in reply to:  17 ; comment:25 by stoecker, 8 years ago

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?

in reply to:  25 comment:26 by Don-vip, 8 years ago

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 by Don-vip, 8 years ago

@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 by Don-vip, 8 years ago

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

in reply to:  27 comment:29 by bastiK, 8 years ago

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 by Don-vip, 8 years ago

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 by bastiK, 8 years ago

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

comment:32 by Don-vip, 8 years ago

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 by Don-vip, 8 years ago

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

in reply to:  32 comment:34 by bastiK, 8 years ago

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 by Don-vip, 8 years ago

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

comment:36 by bastiK, 8 years ago

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 by bastiK, 8 years ago

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 by wiktorn, 8 years ago

In 10076/josm:

Better error reporting for hash mismatch.

See: #12264

comment:39 by wiktorn, 8 years ago

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 8 years ago by wiktorn (previous) (diff)

comment:40 by wiktorn, 8 years ago

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 by stoecker, 8 years ago

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

comment:42 by stoecker, 8 years ago

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

comment:43 by stoecker, 8 years ago

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.

by wiktorn, 8 years ago

Attachment: CertificateAmendment.patch added

Corrected patch

in reply to:  43 comment:44 by wiktorn, 8 years ago

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.

in reply to:  40 comment:45 by bastiK, 8 years ago

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 by stoecker, 8 years ago

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 by stoecker, 8 years ago

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 by wiktorn, 8 years ago

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 by wiktorn, 8 years ago

In 10085/josm:

Add Certum CA certificate used by GUGiK in Poland.

See: #12264

comment:50 by stoecker, 8 years ago

In 10088/josm:

see #12264 - revert r10085

comment:51 by stoecker, 8 years ago

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 by wiktorn, 8 years ago

Done in #12710

comment:53 by Don-vip, 8 years ago

Milestone: 16.0316.04

Milestone renamed

comment:54 by Don-vip, 8 years ago

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

comment:55 by bastiK, 8 years ago

What does it mean for us?

comment:56 by Don-vip, 8 years ago

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?

in reply to:  56 ; comment:57 by stoecker, 8 years ago

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.

in reply to:  56 comment:58 by bastiK, 8 years ago

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

in reply to:  57 ; comment:59 by Don-vip, 8 years ago

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.

in reply to:  59 comment:60 by bastiK, 8 years ago

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 by bastiK, 8 years ago

In 10156/josm:

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

comment:62 by stoecker, 8 years ago

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 by bastiK, 8 years ago

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 by bastiK, 8 years ago

In 10157/josm:

see #12264 - add TLS test url with SNI

comment:65 by Don-vip, 8 years ago

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

comment:66 by Don-vip, 8 years ago

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 by Don-vip, 8 years ago

In 10324/josm:

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

comment:69 by Don-vip, 8 years ago

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 by bastiK, 7 years ago

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

in reply to:  70 comment:71 by stoecker, 7 years ago

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 by bastiK, 7 years ago

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 by bastiK, 7 years ago

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

comment:74 by bastiK, 7 years ago

see #14652 - Remove Let's Encrypt certificate

comment:75 by Don-vip, 6 years ago

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
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.