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
MUST NOT for conforming CAs, so you should never issue a certificate
with those fields).
A CA certificate (i.e. an intermediate certificate) is required to have
a basicConstraints extension - and must be a version three certificate.
If you do this (support V1 cert gen), I'd make it a side effect of
whether or not you add extensions instead of a discrete option.
Later, Mike
On 5/17/2016 7:45 AM, Sean Mullan wrote:
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 support may cause users to (accidentally) start using them in
practice, which would not be good. PKIX (RFC 3280) states that
"Conforming implementations may choose to reject all version 1 and
version 2 intermediate certificates." (RFC 5280, section 6.1.4 step k).
Thanks,
Sean
On 05/17/2016 12:44 AM, Wang Weijun wrote:
https://bugs.openjdk.java.net/browse/JDK-8157109 filed.
--Max
On May 17, 2016, at 12:25 PM, Xuelei Fan <xuelei....@oracle.com> 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 (for example for testing purpose), version 1
self-signed certificate may still be useful.
It would be a low priority, but may be nice to add an option to support
specified certificate version number for certificate generation.
Thanks,
Xuelei
