Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Enroll Certificate

Learn about how to enroll and manage various PKI certificates.

A certificate authority (CA) issues digital certificates, which helps to establish a secure connection between two endpoints through certificate validation. The following topics describe how to configure CA certificates online or local using Simple Certificate Enrollment Protocol (SCEP):

Enroll Digital Certificates Online: Configuration Overview

You can use either Certificate Management Protocol version 2 (CMPv2) or Simple Certificate Enrollment Protocol (SCEP) to enroll digital certificates. To enroll a certificate online:

  1. Generate a key pair on the device. See Self-Signed Digital Certificates.

  2. Create a CA profile or profiles containing information specific to a CA. See Example: Configure a CA Profile.

  3. For SCEP only, enroll the CA certificate. See Enroll a CA Certificate Online Using SCEP.

  4. Enroll the local certificate from the CA whose CA certificate you have previously loaded. See Example: Enroll a Local Certificate Online Using SCEP.

  5. Configure automatic reenrollment. See Example: Using SCEP to Automatically Renew a Local Certificate.

Online CA Certificate Enrollment

With Simple Certificate Enrollment Protocol (SCEP), you can configure your Juniper Networks device to obtain a certificate authority (CA) certificate online and start the online enrollment for the specified certificate ID. The CA public key verifies certificates from remote peers.

Local Certificate Requests

When you create a local certificate request, the device generates an end entity certificate in PKCS #10 format from a key pair you previously generated using the same certificate ID.

A subject name is associated with the local certificate request in the form of a common name (CN), organizational unit (OU), organization (O), locality (L), state (ST), country (C), and domain component (DC). Additionally, a subject alternative name is associated in the following form:

  • IP address

  • E-mail address

  • Fully qualified domain name (FQDN)

    Specify the subject name in the distinguished name format in quotation marks, including the domain component (DC), common name (CN), serial number (SN), organizational unit name (OU), organization name (O), locality (L), state (ST), and country (C).

    Some CAs do not support an e-mail address as the domain name in a certificate. If you do not include an e-mail address in the local certificate request, you cannot use an e-mail address as the local IKE ID when configuring the device as a dynamic peer. Instead, you can use a fully qualified domain name (if it is in the local certificate), or you can leave the local ID field empty. If you do not specify a local ID for a dynamic peer, enter the hostname.domain-name of that peer on the device at the other end of the IPsec tunnel in the peer ID field.

Enroll a CA Certificate Online Using SCEP

Before you begin:

  1. Generate a public and private key pair.

  2. Create a CA profile.

To enroll a CA certificate online:

  1. Retrieve the CA certificate online using SCEP. (The attributes required to reach the CA server are obtained from the defined CA profile.)

    The command is processed synchronously to provide the fingerprint of the received CA certificate.

  2. Confirm that the correct certificate is loaded. The CA certificate is loaded only when you type yes at the CLI prompt.

    For more information on the certificate, such as the bit length of the key pair, use the command show security pki ca-certificate.

Example: Enroll a Local Certificate Online Using SCEP

This example shows how to enroll a local certificate online using Simple Certificate Enrollment Protocol (SCEP).

Requirements

Before you begin:

Overview

In this example, you configure your Juniper Networks device to obtain a local certificate online and start the online enrollment for the specified certificate ID with SCEP. You specify the URL path to the CA server in the CA profile name ca-profile-ipsec.

You use the request security pki local-certificate enroll scep command to start the online enrollment for the specified certificate ID. (Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, the scep keyword is supported and required.) You must specify the CA profile name (for example, ca-profile-ipsec), the certificate ID corresponding to a previously generated key-pair (for example, qqq), and the following information:

  • The challenge password provided by the CA administrator for certificate enrollment and reenrollment.

  • At least one of the following values:

    • The domain name to identify the certificate owner in IKE negotiations—for example, qqq.example.net.

    • The identity of the certificate owner for IKE negotiation with the e-mail statement—for example, qqq@example.net.

    • The IP address if the device is configured for a static IP address—for example, 10.10.10.10.

Specify the subject name in the distinguished name format in quotation marks, including the domain component (DC), common name (CN), serial number (SN), organizational unit name (OU), organization name (O), locality (L), state (ST), and country (C).

Once the device certificate is obtained and the online enrollment begins for the certificate ID. The command is processed asynchronously.

Configuration

Procedure

Step-by-Step Procedure

To enroll a local certificate online:

  1. Specify the CA profile.

  2. If you are done configuring the device, commit the configuration.

  3. Initiate the enrollment process by running the operational mode command.

    If you define SN in the subject field without the serial number, then the serial number is read directly from the device and added to the certificate signing request (CSR).

Starting in Junos OS Release 19.4R2, a warning message ECDSA Keypair not supported with SCEP for cert_id <certificate id> is displayed when you try to enroll local certificate using an Elliptic Curve Digital Signature Algorithm (ECDSA) key with Simple Certificate Enrollment Protocol (SCEP) as ECDSA key is not supported with SCEP.

Verification

To verify the configuration is working properly, enter the show security pki command.

Example: Using SCEP to Automatically Renew a Local Certificate

You can use either Certificate Management Protocol version 2 (CMPv2) or Simple Certificate Enrollment Protocol (SCEP) to enroll digital certificates. This example shows how to renew the local certificates automatically using SCEP.

Requirements

Before you begin:

Overview

You can enable the device to automatically renew certificates that were acquired by online enrollment or loaded manually. Automatic certificate renewal saves you from having to remember to renew certificates on the device before they expire, and helps to maintain valid certificates at all times.

Automatic certificate renewal is disabled by default. You can enable automatic certificate renewal and configure the device to automatically send out a request to reenroll a certificate before it expires. You can specify when the certificate reenrollment request is to be sent; the trigger for reenrollment is the percentage of the certificate’s lifetime that remains before expiration. For example, if the renewal request is to be sent when the certificate's remaining lifetime is 10 percent, then configure 10 for the reenrollment trigger.

For this feature to work, the device must be able to reach the CA server, and the certificate must be present on the device during the renewal process. Furthermore, you must also ensure that the CA issuing the certificate can return the same DN. The CA must not modify the subject name or alternate subject name extension in the new certificate.

You can enable and disable automatic SCEP certificate renewal either for all SCEP certificates or on a per-certificate basis. You use the set security pki auto-re-enrollment scep command to enable and configure certificate reenrollment. In this example, you specify the certificate ID of the CA certificate as ca-ipsec and set the CA profile name associated with the certificate to ca-profile-ipsec. You set the challenge password for the CA certificate to the challenge password provided by the CA administrator; this password must be the same one configured previously for the CA. You also set the percentage for the reenrollment trigger to 10. During automatic reenrollment, the Juniper Networks device by default uses the existing key pair. A good security practice is to regenerate a new key pair for reenrollment. To generate a new key pair, use the re-generate-keypair command.

Configuration

Procedure

Step-by-Step Procedure

To enable and configure local certificate reenrollment:

  1. To enable and configure certificate reenrollment.

    Starting in Junos OS Release 15.1X49-D40 and Junos OS Release 17.3R1, the scep keyword is supported and required.

  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security pki local-certificate detail operational mode command.

CMPv2 and SCEP Certificate Enrollment

Based on your deployment environment, you can use either Certificate Management Protocol version 2 (CMPv2) or Simple Certificate Enrollment Protocol (SCEP) for online certificate enrollment. This topic describes some of the basic differences between the two protocols.

Table 1 describes the differences between the CMPv2 and SCEP certificate enrollment protocols.

Table 1: Comparison of CMPv2 and SCEP Certificate Enrollment

Attribute

CMPv2

SCEP

Supported certificate types:

DSA, ECDSA, and RSA

RSA only

Supported standards

RFCs 4210 and 4211

Internet Engineering Task Force draft

Certificate enrollment and reenrollment requests and responses differ between CMPv2 and SCEP. With CMPv2, there is no separate command to enroll CA certificates. With SCEP, you enroll CA certificates with the request security pki ca-certificate enroll command and specify the CA profile. A CA profile must be configured with either CMPv2 or SCEP.

Certificate Enrollment with CMPv2

The request security pki local-certificate enroll cmpv2 command uses CMPv2 to enroll a local digital certificate online. This command loads both end-entity and CA certificates based on the CA server configuration. The CA profile must be created prior to CA certificate enrollment because the enrollment URL is extracted from the CA profile.

This topic describes certificate enrollment with the CMPv2 protocol.

Certificate Enrollment and Reenrollment Messages

The CMPv2 protocol mainly involves certificate enrollment and reenrollment operations. The certificate enrollment process includes Initialization Request and Initialization Response messages, while certificate reenrollment includes Key Update Request and Key Update Response messages.

CMPv2 server responds back with Initialization Response (IP). The response contains end-entity certificate along with optional CA certificates. The message integrity and message authenticity of Initialization Response can be verified using shared-secret-information according to RFC 4210. The Initialization Response can also be verified using issuer CA public-key. Before you re-enroll an end-entity certificate, you must have a valid CA certificate enrolled on the device.

The Initialization Response or Key Update Response message can contain an issuer CA certificate or a chain of CA certificates. The CA certificates received in the responses are treated as trusted CA certificates and stored in the receiving device if they are not already present in the trusted CA store. These CA certificates are later used for end-entity certificate validation.

We do not support CA certificate re-enrollment. If a CA certificate expires, you must unenroll the current CA certificate and enroll it back again.

End-Entity Certificate with Issuer CA Certificate

In a simple scenario, the Initialization Response message might contain only an end-entity certificate, in which case the CA information is provided separately. The certificate is stored in the end-entity certificate store.

The Initialization Response message can contain an end-entity certificate as well as a self-signed issuer CA certificate. The end-entity certificate is first stored in the certificate store, and then the CA certificate is checked. If the CA certificate is found and the subject distinguished name (DN) of the CA certificate in the Initialization Response message matches the issuer DN of the end-entity certificate, the CA certificate is stored in the CA certificate store for the CA profile name specified in the CMPv2 certificate enrollment command. If the CA certificate already exists in the CA certificate store, no action is taken.

End-Entity Certificate with CA Certificate Chain

In many deployments, the end-entity certificate is issued by an intermediate CA in a certificate chain. In this case, the Initialization Response message can contain the end-entity certificate along with a list of CA certificates in the chain. The intermediate CA certificates and the self-signed root CA certificates are all required to validate the end-entity certificate. The CA chain might also be needed to validate certificates received from peer devices with similar hierarchies. The following section describes how certificates in the CA chain are stored.

In Figure 1, the Initialization Response message includes the end-entity certificate and three CA certificates in a certificate chain.

Figure 1: End-Entity Certificate with CA Certificate ChainEnd-Entity Certificate with CA Certificate Chain

The end-entity certificate is stored in the end-entity certificate store. Each CA certificate needs a CA profile. The CA certificate with the subject DN Sub11-CA is the first CA in the chain and is the issuer of the end-entity certificate. It is stored in the CA profile that is specified with the CMPv2 certificate enrollment command.

Each of the remaining CA certificates in the chain is checked for its presence in the CA store. If a CA certificate is not present in the CA store, it is saved and a CA profile is created for it. The new CA profile name is created using the least significant 16 digits of the CA certificate serial number. If the serial number is longer than 16 digits, the most significant digits beyond 16 digits are truncated. If the serial number is shorter than 16 digits, the remaining most significant digits are filled with 0s. For example, if the serial number is 11111000100010001000, then the CA profile name is 1000100010001000. If the serial number is 10001000, then the CA profile name is 0000000010001000.

It is possible that multiple certificate serial numbers can have the same least significant 16 digits. In that case, -00 is appended to the profile name to create a unique CA profile name; additional CA profile names are created by incrementing the appended number, from -01 up to -99. For example, CA profile names can be 1000100010001000, 1000100010001000-00, and 1000100010001000-01.

Example: Manually Generate a CSR for the Local Certificate and Send it to the CA Server

This example shows how to generate a certificate signing request manually.

Requirements

Generate a public and private key. See Self-Signed Digital Certificates.

Overview

In this example, you generate a certificate request using the certificate ID of a public-private key pair you previously generated (ca-ipsec). Then you specify the domain name (example.net) and the associated common name (abc). The certificate request is displayed in PEM format.

You copy the generated certificate request and paste it into the appropriate field at the CA website to obtain a local certificate. (Refer to the CA server documentation to determine where to paste the certificate request.) When the PKCS #10 content is displayed, the MD5 hash and SHA-1 hash of the PKCS #10 file is also displayed.

Configuration

Procedure

Step-by-Step Procedure

To generate a local certificate manually:

  • Specify certificate ID, domain name, and common name.

Verification

To view the certificate signing request, enter the show security pki certificate-request detail command.

Example: Load CA and Local Certificates Manually

This example shows how to load CA and local certificates manually.

Requirements

Before you begin:

Overview

In this example, you download the local.cert and ca.cert certificates and save them to the /var/tmp/ directory on the device.

After you download certificates from a CA, you transfer them to the device (for example, using FTP), and then load them.

You can load the following certificate files onto a device running Junos OS:

  • A local or end-entity (EE) certificate that identifies your local device. This certificate is your public key.

  • A CA certificate that contains the CA's public key.

  • A CRL that lists any certificates revoked by the CA.

    You can load multiple EE certificates onto the device.

Configuration

Procedure

Step-by-Step Procedure

To load the certificate files onto a device:

  1. Load the local certificate.

  2. Load the CA certificate.

  3. Examine the fingerprint of the CA certificate, if it is correct for this CA certificate select yes to accept.

Verification

To verify the certificates loaded properly, enter the show security pki local-certificate and show security pki ca-certificate commands in operational mode.

Delete Certificates (CLI Procedure)

You can delete a local or trusted CA certificate that is automatically or manually generated.

Use the following command to delete a local certificate:

Specify a certificate ID to delete a local certificate with a specific ID, use all to delete all local certificates, or specify system-generated to delete the automatically generated self-signed certificate.

When you delete an automatically generated self-signed certificate, the device generates a new one.

To delete a CA certificate:

Specify a CA profile to delete a specific CA certificate, or use all to delete all CA certificates present in the persistent store.

You are asked for confirmation before a CA certificate can be deleted.