Generating self-signed certificates
A self-signed certificate claims itself as its own issuer, so it is a straightforward process to create one. It’s convenient for testing, but because no clients trust it by default, it’s not recommended as a listener certificate for production use.
The manage-certificates tool offers a generate-self-signed-certificate subcommand that can be used to create one. In addition to the arguments used to provide information about the key store, certificate alias, and optional private key password, the following arguments are also available.
Argument | Description |
---|---|
|
The subject distinguished name (DN) for the certificate to create. This must be provided. |
|
The number of days that the certificate is valid. If this is not provided, a default value of 365 is used. |
|
A timestamp that indicates when the certificate should begin its validity window. The value should be in the form YYYYMMDDhhmmss (for example, 20190102030405 indicates January 2, 2019 at 3:04:05 a.m.) and is assumed to be in the local time zone. If this is not provided, then the current time is used. |
|
The name of the algorithm to use to generate the key pair. For a listener certificate, the value is typically either “RSA” or “EC”. This cannot be used in conjunction with the |
|
The length of the key to generate, in bits. This must be provided if the |
|
The name of the algorithm to use to sign the certificate. Typical signature algorithms are SHA256withRSA for certificates with RSA keys, or SHA256withECDSA for certificates with elliptic curve keys. This must not be provided if the |
|
Indicates that the new certificate should replace an existing certificate in the key store (in the same alias) and that the key for that certificate should be re-used. |
|
Indicates that when replacing an existing certificate, the new certificate should have the same set of extensions as the existing certificate. If the |
|
Indicates that the certificate should have a subject alternative name extension with the provided DNS name. The given name should be fully qualified, although it can contain an asterisk as a wildcard in the leftmost component. This argument can be provided multiple times if multiple DNS names are to be included in the subject alternative name extension. |
|
Indicates that the certificate should have a subject alternative name extension with the provided IP address. The given address must be a valid IPv4 or IPv6 address, with no wildcards allowed. This argument can be provided multiple times if multiple IP addresses are to be included in the subject alternative name extension. |
|
Indicates that the certificate should have a subject alternative name extension with the provided email address. This argument can be provided multiple times if multiple email addresses are to be included in the subject alternative name extension. |
|
Indicates that the certificate should have a subject alternative name extension with the provided URI. This argument can be provided multiple times if multiple URIs are to be included in the subject alternative name extension. |
|
Indicates that the certificate should have a subject alternative name extension with the provided object identifier (OID). The given value must be a valid OID. This argument can be provided multiple times if multiple OIDs are to be included in the subject alternative name extension. |
|
Indicates that the certificate should have a basic constraints extension with the specified value (which must be either |
|
Indicates that the basic constraints extension should include a path length constraint element with the specified value. This can only be used if |
|
Indicates that the certificate should have a key usage extension with the specified value. Allowed values include |
|
Indicates that the certificate should have an extended key usage extension with the specified value. Allowed values include |
For example, a command like the following can be used to generate a self-signed server certificate.
$ bin/manage-certificates generate-self-signed-certificate \
--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-ip-address 1.2.3.4 \
--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 following self-signed certificate:
Subject DN: CN=ds.example.com,O=Example Corp,C=US
Issuer DN: CN=ds.example.com,O=Example Corp,C=US
Validity Start Time: Monday, January 27, 2020 at 03:40:13 PM CST (0 seconds ago)
Validity End Time: Tuesday, January 26, 2021 at 03:40:13 PM CST (364 days, 23 hours, 59 minutes, 59 seconds from now)
Validity State: The certificate is currently within the validity window.
Signature Algorithm: SHA-256 with ECDSA
Public Key Algorithm: EC (secP256r1)
SHA-1 Fingerprint: 4f:41:82:7f:08:e9:d8:05:8c:19:8b:3e:5b:bc:59:98:d3:15:71:3a
SHA-256 Fingerprint: 76:e6:8e:c5:c8:8d:27:ce:2b:85:b9:8c:9d:49:3c:06:f4:40:f1:d0:70:67:39:24:fc:31:bc:f8:51:83:f2:42