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

[schoen]

@don-vip, I believe we can apply to it but it presumably won't be retroactive: all clients will need to update to newer Java releases in order to accept the new root certificate list, unlike Microsoft's on-the-fly distribution of roots to clients, for example.

[don-vip]

You're absolutely right. Only new versions of JDK provide updates to this list. In fact updates are not frequent. The last one occured recently with JDK 8u51. In our case that would not be a problem as we tell to all of our users to use recent versions of Java, but that could be problematic for others.

[nneul]

Yeah, only way to do it would be to get another cross signature that is in the trust list.

[schoen]

@don-vip, I will ask at ISRG to see if we can apply to the Oracle root program or if we've already done so.

[don-vip]

Thanks a lot! In case of you would also consider @nneul's suggestion to get another cross signature that is in the current trust list, I just have extracted it from latest version of Java (8u66) with this small program. The list contains 93 entries:

1: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
2: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
3: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
4: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
5: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
6: CN=AffirmTrust Commercial, O=AffirmTrust, C=US
7: CN=AffirmTrust Networking, O=AffirmTrust, C=US
8: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US
9: CN=AffirmTrust Premium, O=AffirmTrust, C=US
10: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US
11: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US
12: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
13: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
14: CN=Buypass Class 2 Root CA, O=Buypass AS-983163327, C=NO
15: CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO
16: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
17: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
18: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL
19: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL
20: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
21: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU
22: CN=Class 2 Primary CA, O=Certplus, C=FR
23: CN=Class 3P Primary CA, O=Certplus, C=FR
24: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
25: CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
26: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
27: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
28: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
29: CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
30: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US
31: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
32: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
33: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
34: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
35: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
36: CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US
37: CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US
38: CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US
39: CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US
40: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
41: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
42: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
43: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
44: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
45: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
46: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
47: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
48: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU
49: CN=QuoVadis Root CA 2, O=QuoVadis Limited, C=BM
50: CN=QuoVadis Root CA 3, O=QuoVadis Limited, C=BM
51: CN=QuoVadis Root Certification Authority, OU=Root Certification Authority, O=QuoVadis Limited, C=BM
52: CN=SecureTrust CA, O=SecureTrust Corporation, C=US
53: CN=Sonera Class1 CA, O=Sonera, C=FI
54: CN=Sonera Class2 CA, O=Sonera, C=FI
55: CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US
56: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US
57: CN=SwissSign Gold CA - G2, O=SwissSign AG, C=CH
58: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
59: CN=SwissSign Silver CA - G2, O=SwissSign AG, C=CH
60: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
61: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
62: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE
63: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE
64: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
65: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
66: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
67: CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
68: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
69: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
70: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
71: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
72: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
73: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
74: CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
75: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
76: CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
77: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US
78: CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US
79: CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
80: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
81: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
82: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
83: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
84: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
85: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
86: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP
87: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
88: OU=Security Communication RootCA2, O="SECOM Trust Systems CO.,LTD.", C=JP
89: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
90: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
91: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
92: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
93: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd.", C=TW

[rugk]

unlike Microsoft's on-the-fly distribution of roots to clients, for example.

Ah, yes that thing...
You talk about as if it is such nice...

[schoen]

@don-vip, our director told me that ISRG has already applied to the Oracle root program, so hopefully our application will be accepted and future versions of Java will trust our certificates.

[PeterMount]

I've just hit this issue my self. Whilst beta testing I found maven wouldn't accept the cert (I have proxied Nexus on a whitelisted domain) & maven was failing with:

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The temporary solution (until Oracle adds it to the JDK) was to use the following to manually add the certificate chain to the JDK:

Presuming:

• JAVA_HOME is the location of the JDK, i.e. for me it's /usr/local/java/jdk1.8.0_66
• chain.pem is the certificate chain from lets-encrypt

The following command will add it to the local JDK:

keytool -trustcacerts \
    -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit \
    -noprompt -importcert -file chain.pem

Peter

[PeterMount]

I forgot to add before subitting that reply: The changeit password in the command above is the actual keystore password - before anyone asks for what it is

[Firefishy]

You can edit the post. There is an edit button underneath your own posts.

[samuel]

Also there are still a lot of services that are being actively used that are based upon ancient technology like Java 6, that unfortunately don't work with the current version of letsencrypt certificates. Namely Apple's iTunes crawler.

Hopefully it will be replaced some day, but I guess this still could take years.

I guess the only vector here would be to open a bug report with Apple trying to encourage them to replace those relics?

[qqilihq]

I'm experiencing exactly this issue. In my case I would like to distribute some software via an Eclipse update site, where I had planned to use a Let's Encrypt certificate. As described above, the installation fails, because the certificate is not trusted.

What I did not fully get from above's comments (apologies, I'm not a certificate/security pro): Is there a possibility to support older JREs (starting from 1.7 in my specific case) in the future "out of the box" without having to alter the default keystore? If so, are there any plans to do so? Or will I have to refrain to a different certificate provider?

Many thanks.

[nneul]

The only way that will be possible is if LE gets a cross-signature from one of the CA's that is already trusted by the older JRE. I would expect that is far less likely than future JRE/JDK getting an additional CA added since the latter has a clearly defined process, and the others are subject to the individual policies of and negotiation with one of the existing CAs.

[kelunik]

http://alvinalexander.com/blog/post/java/simple-https-example

Works fine for me with LE issued certificates.

java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

[xored]

Confirmed NOT working with java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[kelunik]

Which certificate store does Java use? Does it use the system one? Really don't see any issue here on Linux with Java. Which domain did you test?

[nhnb]

It works on OpenJDK on Ubuntu. But Oracle Java does not accept it; not even on Ubuntu.

Since there is no OpenJDK für Microsoft Windows, I assume that is broken for all java based Feed readers on Windows.

[PeterMount]

Did you try the oracle java with the openJDK's keystore? It could simply be that the openJDK one's been updated to include the relevant root certs

[nneul]

OpenJDK on ubuntu definitely uses a different keystore. You can look at the contents with:

keytool -keystore /etc/ssl/certs/java/cacerts -storepass changeit -list

Similar command for the Oracle JRE/JDK keystore

[nneul]

This is the root that allows it to trust LE:

debian:dst_root_ca_x3.pem, Nov 9, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13