Hi -
To be very specific here - if a certificate has extensions, it MUST be
version 3, otherwise it SHOULD be version 1, but may be version 2 or 3.
(If a certificate has either of the issuer or subject unique ID fields,
it must be at least version 2 - but those fields are deprecated as a
MUS
On 05/17/2016 12:12 PM, Xuelei Fan wrote:
JDK still support version 1 cert. Developers may want to test
version 1 support of their applications. I agree that version 1
should be fade out although it is still actively used the practice,
especially as self signed cert.
I agree that we need to c
JDK still support version 1 cert. Developers may want to test version 1
support of their applications. I agree that version 1 should be fade out
although it is still actively used the practice, especially as self signed cert.
It may be something that we only want to consider for self-signed ce
Hi Xuelei,
Can you elaborate under what circumstances this is useful for testing?
X.509 v3 was first published in 1996, and v1 certificates should be
pretty much non-existent these days (although there are some root certs
that are still v1). v1 certificates do not support extensions. Adding
s
https://bugs.openjdk.java.net/browse/JDK-8157109 filed.
--Max
> On May 17, 2016, at 12:25 PM, Xuelei Fan wrote:
>
> Hi,
>
> Keytool used to generate version 1 self-signed certificates. Now it is
> mandatory to be version 3. Default version 3 should be OK. However, in
> some circumstances (f
Hi,
Keytool used to generate version 1 self-signed certificates. Now it is
mandatory to be version 3. Default version 3 should be OK. However, in
some circumstances (for example for testing purpose), version 1
self-signed certificate may still be useful.
It would be a low priority, but may be
