Tip

This is the documentation for the 22.06 version. Looking for the documentation of the latest version? Have a look here.

Certificate Authority Management

As mentioned in Public Key Infrastructure, a Certificate Authority (CA) provides a starting point for a chain of trust between entities using certificates. A CA will sign a certificate showing that it is valid, and as long as an entity trusts the CA, it knows it can trust certificates signed by that CA.

By creating or importing a CA into TNSR, TNSR can use that CA to validate other certificates or sign new certificate requests. These certificates can then be used to identify clients connecting to the RESTconf service or other similar purposes.

A CA can be managed in several ways in TNSR. For example:

  • Import a CA generated by another device by copy/paste in the CLI

  • Import a CA generated by another device from a file

  • Generate a new private key and CSR, then self-sign the CSR and set the CA property. The resulting CA is automatically available as a TNSR CA.

Import a CA

TNSR can import a CA from the terminal with copy/paste, or from a file. When importing a CA, the key is optional for validation but required for signing. To import the key, see Key Management. Import the key with the same name as the CA.

To import a CA from the terminal, use the enter command. In this example, a CA named tnsrca will be imported from the terminal by TNSR:

# pki ca tnsrca enter
Type or paste a PEM-encoded certificate.
Include the lines containing 'BEGIN CERTIFICATE' and 'END CERTIFICATE'
-----BEGIN CERTIFICATE-----
<cert data>
-----END CERTIFICATE-----
tnsr(config)#

Next, import the private key using the same name:

tnsr(config)# pki private-key tnsrca enter
Type or paste a PEM-encoded private key.
Include the lines containing 'BEGIN PRIVATE KEY' and 'END PRIVATE KEY'
-----BEGIN PRIVATE KEY-----
<key data>
-----END PRIVATE KEY-----

Alternately, import the CA and key from the filesystem:

tnsr(config)# pki ca otherca import otherca.crt
tnsr(config)# pki private-key otherca import otherca.key

Creating a Self-Signed CA

TNSR can also create a self-signed CA instead of importing an external CA. For internal uses, this is generally a good practice since TNSR does not need to rely on public CA entries to determine trust for its own clients.

First, generate a new private key for the CA:

tnsr(config)# pki private-key selfca generate
-----BEGIN PRIVATE KEY-----
<key data>
-----END PRIVATE KEY-----

Next, create a new CSR for the CA:

tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name selfca
tnsr(config)# pki signing-request set subject-alt-names add hostname selfca
tnsr(config)# pki signing-request set digest sha256
tnsr(config)# pki signing-request selfca generate
-----BEGIN CERTIFICATE REQUEST-----
<csr data>
-----END CERTIFICATE REQUEST-----

Finally, have TNSR self-sign the CSR while setting the CA flag on the resulting certificate:

tnsr(config)# pki signing-request selfca sign self enable-ca true
-----BEGIN CERTIFICATE-----
<cert data>
-----END CERTIFICATE-----

After signing, the newly created CA is ready for immediate use:

tnsr(config)# pki ca list
    tnsrca
    selfca

Intermediate CAs

In some cases a CA may rely on another CA. For example, if a root CA signs an intermediate CA and the intermediate CA signs a certificate, then both the root CA and intermediate CA are required by the validation process.

To show this relationship in TNSR, a CA may be appended to another CA:

tnsr(config)# pki ca <root ca name> append <intermediate ca name>

In the above command, both CA entries must be present in TNSR before using the append command.

Using a CA to sign a CSR

A CA in TNSR with a private key present can also sign a client certificate. The typical use case for this is for RESTconf clients which must have a certificate recognized by a known CA associated with the RESTconf service.

First, generate a client private key and CSR:

tnsr(config)# pki private-key tnsrclient generate
-----BEGIN PRIVATE KEY-----
<key data>
-----END PRIVATE KEY-----
tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name tnsrclient.example.com
tnsr(config)# pki signing-request set subject-alt-names add hostname tnsrclient.example.com
tnsr(config)# pki signing-request set digest sha256
tnsr(config)# pki signing-request tnsrclient generate
-----BEGIN CERTIFICATE REQUEST-----
<csr data>
-----END CERTIFICATE REQUEST-----

Then, sign the certificate:

tnsr(config)# pki signing-request tnsrclient sign ca-name tnsrca days-valid 365 digest sha512 enable-ca false
-----BEGIN CERTIFICATE-----
<cert data>
-----END CERTIFICATE-----

The sign command takes several parameters, each of which has a default safe for use with client certificates in this context. The above example uses these defaults, but specifies them manually to show how the parameters function. The available parameters are:

days-valid:

The number of days the resulting certificate will be valid. The default is 365 days (one year). When the certificate expires, it must be signed again for a new term. Certificates with a shorter lifetime are more secure, but longer lifetimes are more convenient.

digest:

The hash algorithm used to sign the certificate. The default value is sha512.

enable-ca:

A boolean value which sets the CA flag in the resulting certificate. If a CSR is signed as a CA, the resulting certificate can then be used to sign other certificates. For end user certificates this is not necessary or desired, so the default is false.

Other CA Operations

The remaining basic CA operations allow management of CA entries.

To view a list of all CA entries:

tnsr(config)# pki ca list
    tnsrca
    selfca

To view the contents of a CA certificate:

tnsr(config)# pki ca tnsrca get
-----BEGIN CERTIFICATE-----
<cert data>
-----END CERTIFICATE-----

To delete a CA entry:

tnsr(config)# pki ca tnsrca delete