RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format

Weijun Wang weijun.wang at oracle.com
Sun Jun 2 08:48:04 UTC 2019


Oops, I thought this is about another RFE

  8193255: Root Certificates should be stored in text format and assembled at build time

So, are you proposing to simply put the long PEM bundle as the final cacerts in the release? In fact, I've proposed this before [1] but there were no response.

The missing of alias is still a problem. There is also a compatibility impact as someone out there might be opening cacerts directly.

Thanks,
Max

[1] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016623.html

> On Jun 2, 2019, at 4:34 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> The main reason I put each cert in an individual file is for the file name, which will be used as the alias in the cacerts keystore.
> 
> If all certs are in a single file, I know I can add attribute lines like "alias: name [jdk]" before each PEM block but these extra lines are not well defined and I don't like depending of them.
> 
> Anyone else also preferring this format?
> 
> Thanks,
> Max
> 
>> On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>> 
>> Am 2019-05-31 um 05:32 schrieb Weijun Wang:
>>> Please review the CSR at
>>> 
>>>   https://bugs.openjdk.java.net/browse/JDK-8224891
>>> 
>>> (Oh, I hate the CSR having a different bug id.)
>>> 
>>> Basically, with this change, the cacerts file can be loaded with
>>> 
>>>   KeyStore.getInstance("JKS" or "PKCS12").load(stream, null or anything) or
>>>   KeyStore.getInstance(new File("cacerts"), null or anything)
>>> 
>>> so hopefully all your old code should still work.
>>> 
>>> I've also opened another RFE [1] that intends to find a different way to tag jdkCA entries in cacerts other than appending "[jdk]" to the alias.
>> 
>> Can you please explain why not simple PEM bundles like OpenSSL have been
>> chosen? This could have eased maintenance by factors, plus it is easy
>> greppable.
> 




More information about the security-dev mailing list