Missing root CAs in cacerts

Mon May 18 07:59:40 UTC 2020

On 2020-05-17 01:09, Martin Buchholz wrote:
> The mozilla team seems to be doing a good job of maintaining their
> collection of cacerts, and they have become something of an industry
> standard.
I know wget uses this database as their source for cacarts. Are there more?

I've personally run into the issue of missing CAs from Java. It was 
infuriatingly hard to debug and understand why I was able to access a 
web resource from the browser, and from wget, but the Java tool designed 
to download it failed, with a very non-descriptive error message. So I'm 
all for moving to a industry standard base for cacerts.

/Magnus
>
> openjdk could probably include those cacerts with the openjdk sources;
> perhaps there is some hesitation about legalities.
>
> On Sat, May 16, 2020 at 1:21 AM Peter Tribble <peter.tribble at gmail.com> wrote:
>> On Fri, May 15, 2020 at 10:54 AM Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com> wrote:
>>
>>> On 2020-05-14 19:44, Andreas Ahlenstorf wrote:
>>>> Hi!
>>>>
>>>> At AdoptOpenJDK, we get support requests because root CAs are missing
>>> from the bundled cacerts file (lib/security/cacerts). We ship the same
>>> cacerts file as OpenJDK. As a result, our users cannot connect to various
>>> servers using Java's built-in APIs while their browsers can. An example URL
>>> that fails is https://api.insee.fr/catalogue/ (root CA: Certigna).
>>>> Replacing the bundled cacerts file with one generated from Mozilla's
>>> list of trusted CAs [1] fixes the problem. [2] contains the full analysis
>>> based on OpenJDK 14.0.1 including an executable test case.
>>>> Questions:
>>>>
>>>> * Does OpenJDK want to do something about that?
>>>> * Is there interest for a collaboration in that area, especially by
>>> other distributors of OpenJDK like Azul, BellSoft?
>>>> Commentary:
>>>>
>>>>   From a end user's perspective, it is inscrutable why it is possible to
>>> connect to a website using their browser, curl, but not Java. While there
>>> might be some differences because of policy, OpenJDK should strive to match
>>> the browser's list of trusted CAs a closely as possible. As of OpenJDK
>>> 14.0.1, cacerts contains 93 entries while Mozilla's list contains 138.
>>>   From my personal point of view, it seems to make sense to use the
>>> Mozilla list. We already use e.g. the Mozilla Public Suffix List, which
>>> is a well-handled curated list.
>>>
>>> However, a change of the set of root CAs can certainly have user
>>> implications. Have you analyzed which CAs Mozilla is shipping that
>>> OpenJDK is missing? And -- even more importantly to avoid regressions
>>> for OpenJDK users -- is OpenJDK currently shipping any root CA
>>> certificates that Mozilla is missing?
>>>
>> This is from a month or so back (I think maybe one of the certs that's in
>> the jdk has since
>> been removed). The following certs are those in jdk that aren't in the
>> current Mozilla bundle.
>> Generally they might expire soon (and have been replaced with newer roots,
>> intermediates
>> having been cross-signed), and there's a bunch of 1024-bit roots that
>> really shouldn't
>> be in use anywhere.
>>
>> # this one expires shortly, should be covered by USERTrust?
>> Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust
>> AB, C=SE
>> Valid from: Tue May 30 11:38:31 BST 2000 until: Sat May 30 11:38:31 BST 2020
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> # this one expires shortly, should be covered by USERTrust?
>> Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust
>> AB, C=SE
>> Valid from: Tue May 30 11:44:50 BST 2000 until: Sat May 30 11:44:50 BST 2020
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> #
>> Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL
>> Valid from: Tue Jun 11 11:46:39 BST 2002 until: Fri Jun 11 11:46:39 BST 2027
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> #
>> Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC
>> Camerfirma SA CIF A82743287, C=EU
>> Valid from: Tue Sep 30 17:13:43 BST 2003 until: Wed Sep 30 17:13:44 BST 2037
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> # this one expires shortly (replaced by OpenTrust)
>> Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
>> Valid from: Tue May 26 01:00:00 BST 2009 until: Tue May 26 01:00:00 BST 2020
>> Signature algorithm name: SHA256withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> # this one expires shortly [there's a new LuxTrust Global Root 2]
>> Issuer: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU
>> Valid from: Thu Mar 17 09:51:37 GMT 2011 until: Wed Mar 17 09:51:37 GMT 2021
>> Signature algorithm name: SHA256withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> #
>> Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
>> Valid from: Wed Oct 25 09:36:00 BST 2006 until: Sat Oct 25 09:36:00 BST 2036
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 4096-bit RSA key
>>
>> # 1024-bit
>> Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte,
>> L=Durbanville, ST=Western Cape, C=ZA
>> Valid from: Wed Jan 01 00:00:00 GMT 1997 until: Fri Jan 01 23:59:59 GMT 2021
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 1024-bit RSA key
>>
>> # this one has already expired
>> Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The
>> USERTRUST Network, L=Salt Lake City, ST=UT, C=US
>> Valid from: Fri Jul 09 19:31:20 BST 1999 until: Tue Jul 09 19:40:36 BST 2019
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 2048-bit RSA key
>>
>> # 1024-bit
>> Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server
>> CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape
>> Town, ST=Western Cape, C=ZA
>> Valid from: Thu Aug 01 01:00:00 BST 1996 until: Fri Jan 01 23:59:59 GMT 2021
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 1024-bit RSA key
>>
>> # 1024-bit
>> Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign,
>> Inc.", C=US
>> Valid from: Mon Jan 29 00:00:00 GMT 1996 until: Thu Aug 03 00:59:59 BST 2028
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 1024-bit RSA key
>>
>> # 1024-bit
>> Issuer: 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
>> Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 1024-bit RSA key
>>
>>
>> # 1024-bit
>> Issuer: 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
>> Valid from: Mon May 18 01:00:00 BST 1998 until: Wed Aug 02 00:59:59 BST 2028
>> Signature algorithm name: SHA1withRSA
>> Subject Public Key Algorithm: 1024-bit RSA key
>>
>>
>> --
>> -Peter Tribble
>> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/