Generating certificate signing requests
A certificate signing request (CSR) contains all of the information that a certification authority requires to issue a certificate.
RFC 2986 defines the request format, also known as PKCS #10, and includes the following elements:
-
Certificate signing request version
-
Requested subject distinguished name (DN) for the certificate
-
Public key for the requested certificate
-
Requested set of extensions for the certificate
-
Signature that proves the requester has the private key for the given public key
To create a certificate signing request, use the manage-certificates generate-certificate-signing-request
command, which performs the following steps:
-
Generated a public and private key pair.
-
Stores the key pair in a key store with a given alias.
-
Outputs the certificate signing request to the terminal.
-
Optionally writes the certificate signing request to a file.
Because a certificate signing request contains many of the same elements as a certificate, the command to generate one takes most of the same arguments as for generating a self-signed certificate. The following arguments are unavailable when generating a CSR:
-
--replace-existing-certificate
-
--days-valid {number}
-
--validity-start-time {timestamp}
The following arguments are available when generating a certificate signing request but not when generating a self-signed certificate:
--output-file {path}
-
Path to a file to which the certificate signing request is written. If this value is not provided, the request is written only to the terminal in PEM form.
--output-format {value}
-
Format to use when writing the certificate signing request. This value can be
PEM
orDER
, but the DER format is used only in conjunction with the--output-file
argument. Defaults toPEM
if the--output-format {value}
argument is not provided. --use-existing-key-pair
-
Indicates that the CSR uses a key pair that already exists in the key store with the given alias, rather than generating a new key pair, in which case the specified alias must not already be in use in the key store.
The following example command creates a CSR.
bin/manage-certificates generate-certificate-signing-request \ --output-file ds1-cert.csr \ --output-format PEM \ --keystore config/keystore \ --keystore-password-file config/keystore.pin \ --keystore-type JKS \ --alias server-cert \ --subject-dn "CN=ds.example.com,O=Example Corp,C=US" \ --key-algorithm EC \ --key-length-bits 256 \ --signature-algorithm SHA256withECDSA \ --subject-alternative-name-dns ds.example.com \ --subject-alternative-name-dns ds1.example.com \ --subject-alternative-name-dns localhost \ --subject-alternative-name-ip-address 1.2.3.4 \ --subject-alternative-name-ip-address 127.0.0.1 \ --subject-alternative-name-ip-address 0:0:0:0:0:0:0:1 \ --key-usage digital-signature \ --key-usage key-encipherment \ --key-usage key-agreement \ --extended-key-usage server-auth \ --extended-key-usage client-auth Successfully created a new JKS keystore. Successfully generated the key pair to use for the certificate signing request. Successfully wrote the certificate signing request to file '/ds/build/package/PingDirectory/ds1-cert.csr'.
If the contents of the resulting CSR file are made available to a certification authority to be signed, the resulting signed certificate can be imported into the key store.
To print the contents of a certificate signing request file, use the display-certificate-signing-request-file
subcommand, which supports the following arguments:
--certificate-signing-request-file {path}
-
Path to the file that contains the certificate signing request to display.
--verbose
-
Indicates that the command is expected to display verbose information about the request, rather than a basic information set.
The following example demonstrates the basic output from the command.
$ bin/manage-certificates display-certificate-signing-request-file \
--certificate-signing-request-file ds1-cert.csr
PKCS #10 Certificate Signing Request Version: v1
Subject DN: CN=ds.example.com,O=Example Corp,C=US
Signature Algorithm: SHA-256 with ECDSA
Public Key Algorithm: EC (secP256r1)
The following example demonstrates the verbose output.
$ bin/manage-certificates display-certificate-signing-request-file \
--certificate-signing-request-file ds1-cert.csr \
--verbose
PKCS #10 Certificate Signing Request Version: v1
Subject DN: CN=ds.example.com,O=Example Corp,C=US
Signature Algorithm: SHA-256 with ECDSA
Signature Value:
30:45:02:20:46:31:be:9e:6d:2f:0e:e3:d0:80:5c:88:ef:da:86:07:fd:15:b7:62:
83:45:39:0a:c9:f2:f9:17:eb:08:94:ff:02:21:00:c8:bd:df:57:fa:ea:8c:04:
df:c5:27:76:e5:b3:3b:4f:df:ec:d3:e4:09:5b:c0:6c:7b:86:39:ec:d0:0e:c1:64
Public Key Algorithm: EC (secP256r1)
Elliptic Curve Public Key Is Compressed: false
Elliptic Curve X-Coordinate:
2086285379047579631978894716670982397622966387996624365020701122793024
3221133
Elliptic Curve Y-Coordinate:
479697739226644990505743464941788269420922508654777168408919906254139
60212095
Certificate Extensions:
Subject Key Identifier Extension:
OID: 2.5.29.14
Is Critical: false
Key Identifier:
f2:de:fd:bf:d3:2f:96:ef:01:70:2d:0e:85:f5:fb:17:d5:a0:9e:67
Subject Alternative Name Extension:
OID: 2.5.29.17
Is Critical: false
DNS Name: ds.example.com
DNS Name: ds1.example.com
DNS Name: localhost
IP Address: 1.2.3.4
IP Address: 127.0.0.1
IP Address: 0:0:0:0:0:0:0:1
Key Usage Extension:
OID: 2.5.29.15
Is Critical: false
Key Usages:
Digital Signature
Key Encipherment
Key Agreement
Extended Key Usage Extension:
OID: 2.5.29.37
Is Critical: false
Key Purpose ID: TLS Server Authentication
Key Purpose ID: TLS Client Authentication