Bug ID: JDK-6780416 New keytool commands/options: -gencert, -printcertreq, -ext

Type: Enhancement
Component: security-libs
Sub-Component: java.security
Affected Version: 7

Priority: P4
Status: Closed
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2008-12-04
Updated: 2017-05-16
Resolved: 2011-03-07

JDK 7
7 b50Fixed

Two new commands:

-gencert: Generates a certificate according to a certificate request
-printcertreq: Prints the content of a certificate request

One new option:

-ext: Used in -genkeypair and -gencert to create X.509 certificate extensions in the generated certificates, or in -certreq to show what X.509 certificate extensions are requested in the certificate request.

EVALUATION Minor difference with the previous spec: 1. -sigalg and -validity definitions still consistent with other keytool commands, which means, these options have the same default values, instead of "using the values from the request". In fact, PKCS #10 style certificate request simply does not support the value being requested. 2. {-ext ext} in usage text is changed to {-ext <key>[:critical][=<value>]}

23-02-2009

EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90ab7b4891e3

23-02-2009

EVALUATION Adding to keytool.html of the JDK documentation. Add the following lines into COMMANDS: --------------------------------------------- -gencert {-infile infile} {-outfile outfile} {-ext ext}* {-rfc} {-alias alias} {-sigalg sigalg} {-validity valDays} {-storetype storetype} {-keystore keystore} [-storepass storepass] [-keypass keypass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption} Generates a certificate as a response to a certificate request file (which can be created by the keytool -certreq command). The command reads the request from infile (if omitted, from the standard input), signs it using alias's private key, and output the X.509 certificate into outfile (if omitted, to the standard output). If -rfc is specified, output format is BASE64-encoded PEM; otherwise, a binary DER is created. sigalg specifies the algorithm that should be used to sign the certificate. valDays tells the number of days for which the certificate should be considered valid. ext shows what X.509 extensions will be embedded in the certificate. Read Common Options for the grammar of -ext. -printcertreq {-file file} Prints the content of a PKCS #10 format certificate request, which can be generated by the keytool -certreq command. The command reads the request from file; if omitted, from the standard input. Add the following lines into Common Options: --------------------------------------------- -ext {name{:critical}{=value}} Denotes an X.509 certificate extension. The option can be used in -genkeypair and -gencert to embed extensions into the certificate generated, or in -certreq to show what extensions are requested in the certificate request. The option can appear multiple times. name can be a supported extension name (see below) or an arbitrary OID number. value, if provided, denotes the parameter for the extension; if omitted, denotes the default value (if defined) of the extension or the extension requires no parameter. The ":critical" modifier, if provided, means the extension's isCritical attribute is true; otherwise, false. Currently keytool support these named extensions (case-insensitive): name value BC or BasicConstraints The full form: "ca:{true|false}[,pathlen:<len>]"; or, <len>, a shorthand for "ca:true,pathlen:<len>"; or omitted, means "ca:true" KU or KeyUsage usage(,usage)*, usage can be one of digitalSignature, nonRepudiation (contentCommitment), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly. Usage can be abbreviated with the first few letters (say, dig for digitalSignature) or in camel-case style (say, dS for digitalSignature, cRLS for cRLSign), as long as no ambiguity is found. Usage is case-insensitive. EKU or ExtendedkeyUsage usage(,usage)*, usage can be one of anyExtendedKeyUsage, serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, or any OID string. Named usage can be abbreviated with the first few letters or in camel-case style, as long as no ambiguity is found. Usage is case-insensitive. SAN or SubjectAlternativeName type:value(,type:value)*, type can be EMAIL, URI, DNS, IP, or OID, value is the string format value for the type. IAN or IssuerAlternativeName same as SubjectAlternativeName SIA or SubjectInfoAccess method:location-type:location-value (,method:location-type:location-value)*, method can be "timeStamping", "caRepository" or any OID. location-type and location-value can be any type:value supported by the SubjectAlternativeName extension. AIA or AuthorityInfoAccess same as SubjectInfoAccess. method can be "ocsp", "caIssuers" or any OID. For name as OID, value is the HEX dumped DER encoding of the extnValue for the extension excluding the OCTET STRING type and length bytes. Any extra character other than standard HEX numbers (0-9, a-f, A-F) are ignored in the HEX string. Therefore, both "01:02:03:04" and "01020304" are accepted as identical values. If there's no value, the extension has an empty value field then. A special name "honored", used in -gencert only, denotes how the extensions included in the certificate request should be honored. The value for this name is a comma-seperated list of "all" (all requested extensions are honored), "name{:[critical|non-critical]}" (the named extension is honored, but using a different isCritical attribute) and "-name" (used with all, denotes an exception). Requested extensions are not honored by default. If, besides the -ext honored option, another named or OID -ext option is provided, this extension will be added to those already honored. However, if this name (or OID) also appears in the honored value, its value and criticality overrides the one in the request. The subjectKeyIdentifier extension is always created. For non self-signed certificates, the authorityKeyIdentifier is always created. Add the following into Examples: ------------------------------- How to generate certificates for a typical SSL server. Belows are keytool commands to generate keypairs and certificates for three entities: Root CA (root), Intermadiate CA (ca), and SSL server (server). keytool -keystore root.jks -genkeypair -alias root -ext bc:c keytool -keystore ca.jks -alias ca keytool -keystore server.jks -alias server keytool -keystore root.jks -alias root -exportcert > root.pem keytool -keystore ca.jks -certreq -alias ca | keytool -keystore root.jks -gencert -alias root -ext BC=0 > ca.pem keytool -keystore ca.jks -importcert -alias ca -file ca.pem keytool -keystore server.jks -certreq -alias server | keytool -keystore ca.jks -gencert -alias ca -ext ku:c=dig,kE > server.pem cat root.pem ca.pem server.pem | keytool -keystore server.jks -importcert -alias server

18-02-2009

Relates :	JDK-4615506 - Security certificate request framework
Relates :	JDK-6813402 - keytool cannot -printcert entries without extensions