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:

  1. Generated a public and private key pair.
  2. Stores the key pair in a key store with a given alias.
  3. Outputs the certificate signing request to the terminal.
  4. 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 or DER, but the DER format is used only in conjunction with the --output-file argument. Defaults to PEM 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