Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

gNOI Certificate Management Service

SUMMARY Use the gNOI CertificateManagement service to manage certificates on the target network element.

Overview

The gNOI CertificateManagement service in the gnoi.certificate package handles certificate management on the target network element. The proto definition file is located at https://github.com/openconfig/gnoi/blob/master/cert/cert.proto.

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users to both securely exchange data over networks such as the Internet and verify the identity of the other party. The Junos PKI enables you to manage public key certificates on Junos devices, including downloading, generating, and verifying certificates. The gNOI CertificateManagement service defines operations for certificate management, which is through the Junos PKI. The two main operations are:

  • Install—Install a new certificate using a new certificate ID on the target network device. If the certificate ID already exists, the operation returns an error.

  • Rotate—Replace an existing certificate, which already has an existing certificate ID, on the target network device. If the stream is broken or any steps fail during the process, then the device rolls back to the original certificate.

Figure 1 outlines the workflow for the Install() and Rotate() operations. For both operations, the client can generate the certificate signing request (CSR) itself or request the target to generate the CSR. In either case, the client forwards the CSR to a certificate authority (CA) to request a digital certificate. The client then loads the certificate on the target, either with a new certificate ID for Install() operations or with an existing certificate ID for Rotate() operations. For Rotate() operations, the client should also validate any replacement certificates and finalize or cancel the Rotate() operation based on the success or failure of the validation. If the client cancels the operation, the server rolls back the certificate, key pair, and any CA bundle, if it is present in the request.

Starting in Junos OS Evolved Release 23.1R1, during an Install(), Rotate(), or LoadCertificate() operation, the gNOI server verifies the new end entity certificate using the corresponding CA certificate. Thus, the gNOI server's PKI must include the root CA certificate that verifies the new certificate. You can load the required CA certificate as part of the gNOI CA bundle, or you can load it separately. If the verification fails, the device does not install the new certificate.

Figure 1: gNOI CertificateManagement Service Install and Rotate OperationsgNOI CertificateManagement Service Install and Rotate Operations

The gNOI server supports only one global CA certificate bundle for gNOI services. When you use the gNOI CertificateManagement service to load the CA bundle, the following statements are applicable:

  • The CertificateManagagment service always loads the CA certificate bundle using the ca-profile-group reserved identifier gnoi-ca-bundle.

  • If you use the CertificateManagagment service to load the CA certificate bundle, the device implicitly uses mutual authentication and assumes the following configuration, even though it is not explicitly configured on the device.

  • If the CertificateManagagment service sends a request to load a new CA certificate bundle, the server clears the certificates for the previous CA bundle from the device and loads the new ones.

  • If you use the CertificateManagagment service to load a CA certificate bundle and you also configure the [edit system services extension-service request-response grpc ssl mutual-authentication] statement hierarchy, then the configured statements take precedence.

Thus you can initially set up server-only authentication on the gNOI server and then use the Install() RPC to load the CA certificates. When you use gNOI to load the initial CA certificate bundle, the device performs the following steps:

  • Adds the CA certificates in the Junos PKI.
  • Automatically configures the gNOI CA certificate bundle at the [edit security pki] hierarchy level using the ca-profile-group identifier gnoi-ca-bundle.
  • Switches from server-only authentication to mutual authentication.

The Rotate() RPC does not support switching between authentication modes during the rotate operation. Thus, Rotate() does not support loading the CA certificate bundle on the gNOI server for the first time because it causes the device to switch from server-only authentication to mutual authentication during the operation. When the authentication mode changes, the network device must restart the gRPC stack and the connection is lost. If the stream is broken, the client cannot finalize the rotate request, and the device would roll back to the certificates that were in place before the Rotate() request was initiated.

Note:

The hot-reloading statement at the [edit system services extension-service request-response grpc ssl] hierarchy level only maintains the gRPC session during a certificate update when the authentication mode remains unchanged during the operation. If the authentication mode switches, for example, from server-only to mutual authentication or vice versa, the client disconnects.

Supported RPCs

Table 1 outlines the CertificateManagement service RPCs supported on Junos devices.

Table 1: Supported cert.proto RPCs
RPC Description Introduced in Release
CanGenerateCSR()

Query the target device to determine if it can generate a certificate signing request (CSR) with the specified key type, key size, and certificate type. Supported values:

  • Key type: KT_RSA

  • Key sizes: 1024, 2048, 4096

  • Certificate type: CT_X509

Returns True if the gNOI server supports the specific key type, key size, and certificate type.

Junos OS Evolved 23.1R1

GenerateCSR()

Generate and return a certificate signing request (CSR).

Junos OS Evolved 22.2R1

GetCertificates()

Return the local certificates loaded on the target device.

Junos OS Evolved 22.2R1

Install()

Load a new certificate on the target device by creating a CSR request, generating a certificate based on the CSR, and loading the certificate using a new certificate ID.

Junos OS Evolved 22.2R1

LoadCertificate()

Load a certificate signed by a Certificate Authority (CA) on the target device.

Junos OS Evolved 22.2R1

LoadCertificateAuthorityBundle()

Load a CA certificate bundle on the target device.

Junos OS Evolved 22.2R1

RevokeCertificates()

Revoke the certificates with the specified certificate IDs on the target device.

Junos OS Evolved 23.1R1

Rotate()

Replace an existing certificate on the target device by creating a CSR request, generating a certificate based on the CSR, and loading the certificate using an existing certificate ID.

Junos OS Evolved 22.2R1

Network Device Configuration

To use gNOI certificate management services on Junos devices, you must configure the use-pki and hot-reloading statements for gRPC extensions services. In most cases, you configure the use-pki statement when you configure gRPC services on the network device. The hot-reloading statement is required to maintain the gRPC session when updating certificates that affect the session.

Before you begin:

To configure the network device for CertificateManagement service operations:

  1. Configure the device to use the PKI database for local certificates.
  2. Enable the device to reload certificates without terminating the gRPC session.
  3. Commit the configuration.

Install a Certificate

You can use the CertificateManagement service Install() RPC to load a new certificate on the target device. When you install a new certificate using the Install() operation, you must specify a new certificate ID that does not already exist on the target device. You can also optionally load a CA certificate bundle as part of the Install() operation.

As part of the Install() operation, the device verifies the new certificate. Therefore, the Junos PKI must have the root CA certificate that verifies the new certificate. You can load the required CA certificate as part of the Install() operation, or you can load it separately, prior to the operation, if it is not already in the PKI.

If you install a new local certificate that will be used for gRPC session authentication, you must also update the gRPC server configuration on the device to use the new certificate ID.

Example: Install a Certificate

In this example, the gNOI server has been initially configured with a local certificate only and has not been configured to use mutual authentication. The gNOI client uses the Install() RPC to load a new local certificate and a CA certificate bundle on the device. After the CA bundle is loaded on the gNOI server, the server uses mutual authentication by default. The CA bundle includes the root CA certificate for the client certificate as well as the root CA certificate for the new server certificate.

The client executes the gnoi_cert_install_certificate_csr.py Python application, which performs the following operations:

  • Requests the target to generate a CSR.
  • Gets a signed certificate based on the CSR.
  • Loads the new server certificate, the server's new root CA certificate, and the client's root CA certificate on the target network device.

The application uses the InstallCertificateRequest message with the appropriate parameters to define the requests for generating the CSR and loading the certificates. For each request, the application uses the Install() RPC to send the requests to the network device.

The gnoi_cert_install_certificate_csr.py application imports the grpc_channel module to establish the channel. The grpc_channel module is described in Configure gNOI Services. The application's arguments are stored in the args_cert_install_csr.txt file. The application and argument files are presented here.

gnoi_cert_install_certificate_csr.py

args_cert_install_csr.txt

Execute the Application

When the client executes the application, the application requests the CSR, gets the signed certificate, and loads the new server certificate and CA certificates on the target network device.

After you install the new server certificate, you must configure the server to use that certificate ID for gRPC session authentication, as shown here. In addition, because the Install() operation loaded new CA certificates, the device implicitly uses mutual authentication. As a result, all subsequent gRPC sessions must include the client's certificate and key when establishing the channel.

If you execute the application and provide a certificate ID that already exists on the server, the application returns an ALREADY_EXISTS error, because the Install() operation requires a new certificate ID.

Rotate a Certificate

You can use the CertificateManagement service Rotate() RPC to replace an existing certificate on the target device. When you replace an existing certificate using the Rotate() operation, you must load the certificate using the certificate ID that already exists on the target device. You can also optionally replace the existing gNOI CA certificate bundle as part of the Rotate() operation.

The Rotate() operation is similar to the Install() operation except that the Rotate() operation replaces an existing certificate instead of installing a new certificate. In addition, the client must validate that the updated certificate works and then finalize or cancel the Rotate() request based on the success or failure of the certificate validation.

As part of the Rotate() operation, the device verifies the new certificate. Therefore, the Junos PKI must have the root CA certificate that verifies the new certificate. You can load the required CA certificate as part of the Rotate() operation, or you can load it separately, prior to the operation, if it is not already in the PKI.

Example: Rotate a Certificate

In this example, the client executes the gnoi_cert_rotate_certificate_csr.py Python application, which performs the following operations:

  • Requests the target to generate a CSR.
  • Gets a signed certificate based on the CSR
  • Replaces the node certificate and the gNOI CA bundle on the target network device.
  • Validates the new certificate.
  • Finalizes the Rotate operation.

The application uses the RotateCertificateRequest message with the appropriate parameters to define the requests for generating the CSR and loading the certificate and CA bundle. For each request, the application uses the Rotate() RPC to send the request to the network device. To enable the target device to verify the new node certificate, the application replaces the existing CA bundle with a new CA bundle. The bundle includes both the client CA certificate and the CA certificate required to verify the node certificate.

The application validates that the new certificate works by creating a new gRPC session with the network device and executing a simple Time() RPC, although you can test the session authentication with any RPC. The application finalizes the rotate request if the session is successfully established and cancels the rotate request if the session authentication fails.

The gnoi_cert_rotate_certificate_csr.py application imports the grpc_channel module to establish the channel. The grpc_channel module is described in Configure gNOI Services. The application's arguments are stored in the args_cert_rotate_csr.txt file. The application and argument files are presented here.

gnoi_cert_rotate_certificate_csr.py

args_cert_rotate_csr.txt

It's important to note that the root_ca_cert argument is the server's root CA certificate required for the initial channel credentials. The server_root_ca1 argument is the root CA certificate corresponding to the server's new certificate. The Junos PKI must have the new root CA certificate in order to verify the new local certificate during the Rotate() operation. In addition, the channel credentials for the gRPC session that validates the new certificate use this root CA certificate. Although this example uses the same root CA certificate for the new and old server certificates, these might differ for another case.

Execute the Application

When the client executes the application, the application requests the CSR, gets the signed certificate, and loads the replacement certificate and CA bundle on the target network device. The application then validates the replacement certificate with a new gRPC session that executes a simple Time() RPC. Upon successful validation, the client finalizes the rotate request.

Revoke a Certificate

A gNOI client can use the RevokeCertificates() RPC to remove one or more certificates from the target device. The client includes a RevokeCertificatesRequest message with the list of certificate IDs to revoke.

When the gNOI server receives the RevokeCertificates() request, it processes each certificate ID in the list as follows:

  • If the certificate is present and the revocation is successful, the device removes the certificate from the file system and the Junos PKI and adds the certificate ID to the list of successfully revoked certificates.

  • If the certificate is present and the revocation fails, the device includes the certificate ID and the reason for the failure in the certificate revocation error list.

  • If the certificate is not present, the device considers the revocation operation successful and adds the certificate ID to the list of successfully revoked certificates.

Note:

If the request revokes the certificate used for the current session, the session is not affected.

After processing the request, the gNOI server returns a RevokeCertificatesResponse message that includes:

  • A list of successfully revoked certificate IDs.

  • A list of revocation errors containing the certificate ID and the reason for the failure.

Example: Revoke a Certificate

In this example, the client executes the gnoi_cert_revoke_certificates.py Python application, which revokes two certificates on the server. The first certificate ID is a valid identifier on the device. The second certificate ID is an identifier that does not exist on the device.

The application uses the RevokeCertificatesRequest message with the appropriate parameters to define the request. The application sends the RevokeCertificates() RPC to the network device to perform the operation.

The gnoi_cert_revoke_certificates.py application imports the grpc_channel module to establish the channel. The grpc_channel module is described in Configure gNOI Services. The application's arguments are stored in the args_cert_revoke_certificates.txt file. The application and argument files are presented here.

gnoi_cert_revoke_certificates.py

args_cert_revoke_certificates.txt

Execute the Application

When the client executes the application, the application instructs the target device to revoke the specified certificates. The device returns a list of successfully revoked certificates and any errors. The device deems the operation successful for both the valid certificate ID as well as for the certificate ID that does not currently exist on the device.

Release History Table
Release
Description
23.1R1-EVO
Starting in Junos OS Evolved Release 23.1R1, the Install(), Rotate(), and LoadCertificate() operations verify the new certificate as part of the operation.