OK, now I see, it will probably require a "pem" style, because PKCS12
stores X.509 certs too, "x509" would be too generic.
I must admit, I have never used the KeyStore interface directly, but I
can't image that it would be too hard to add virtual aliases for.
I'd be happy to review your ideas.
Michael
Am 2019-06-02 um 17:00 schrieb Weijun Wang:
But it still has to be a keystore. KeyStore is designed into SSL's TrustManagerFactory. JSSE has system
properties javax.net.ssl.trustStore* pointing to it specifying file name, keystore type, and password. If we
really use a PEM bundle, we might need to define a new keystore type "x509" or "pem".
It's certainly cert-only, it might or might not be read-only. For the same reason I described in the CSR, it
probably should be loadable by KeyStore.getInstance("JKS").
I can do some experiment. This won't go into JDK 13 anyway so there is time to
discuss.
Thanks,
Max
On Jun 2, 2019, at 7:09 PM, Michael Osipov <1983-01...@gmx.net> wrote:
Am 2019-06-02 um 12:36 schrieb Alan Bateman:
On 02/06/2019 09:48, Weijun Wang wrote:
:
There is also a compatibility impact as someone out there might be
opening cacerts directly.
A general point here is that the contents of the lib directory is not a
supported interface, a point that may be relevant to the wording in the
CSR.
Correct, from a user's POV it is completely opaque to me. It is at the
descretion of Oracle just like the mod files, but from a packager's POV
I need to be able to exchange this sytemwide without much hassle wich
neither JDK nor PKCS12 do this atm compared to a PEM bundle.
Michael
