Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Enroll a 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.

Certificate Enrollment

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.

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.

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.

Configure PKI and SSL Forward Proxy to Authenticate Users

For non-domain users, you can configure PKI to validate integrity, confidentiality, and authenticity of traffic. PKI includes digital certificates issued by the CA, certificate validity and expiration dates, details about the certificate owner and issuer, and security policies.

For any non-domain user or domain user on a non-domain machine, the administrator specifies a captive portal to force the user to do firewall authentication (if the SRX Series Firewall supports captive portal for the traffic type). After the user enters a name and password and passes firewall authentication, the SRX Series Firewall gets firewall authentication user/group information and can enforce the user firewall policy to control the user accordingly. In addition to captive portal, if the IP address or user information is not available from the event log, the user can again log in to the Windows PC to generate an event log entry. Then the system generates the user’s authentication entry accordingly.

To enable the SRX Series Firewall to authenticate the users through HTTPs, the SSL forward proxy must be configured and enabled. You need to generate a local certificate, add an SSL termination profile, add an SSL proxy profile, and reference the SSL proxy profile in the security policy. If the SSL forward proxy is not enabled, the SRX Series Firewall cannot authenticate users who are using HTTPS, but for users who are using HTTP, FPT, and Telnet, the authentication can be performed as expected.

To generate PKI and enable SSL forward proxy, perform the following steps:

  1. Generate a PKI public/private keypair for a local digital certificate.

  2. Manually generate a self-signed certificate for the given distinguished name.

  3. Define the access profile to be used for SSL termination services.

  4. Configure the loaded certificate as root-ca in the SSL proxy profile.

  5. Specify the ignore-server-auth-failure option if you do not want to import the entire CA list and you do not want dropped sessions.

  6. Add an SSL termination profile into security policies.

  7. Commit the configuration.

Use Feature Explorer to confirm platform and release support for specific features.

Review the Platform-Specific SSL Termination Services Behavior section for notes related to your platform.

Configure Digital Certificates for Adaptive Services Interfaces

A digital certificate implementation uses the public key infrastructure (PKI), which requires that you generate a key pair consisting of a public key and a private key. The keys are created with a random number generator and are used to encrypt and decrypt data. In networks that do not use digital certificates, an IPsec-enabled device encrypts data with the private key and IPsec peers decrypt the data with the public key.

With digital certificates, the key sharing process requires an additional level of complexity. First, you and your IPsec peers request that a certificate authority (CA) send you a CA certificate that contains the public key of the CA. Next you request the CA to assign you a local digital certificate that contains the public key and some additional information. When the CA processes your request, it signs your local certificate with the private key of the CA. Then you install the CA certificate and the local certificate in your router and load the CA in remote devices before you can establish IPsec tunnels with your peers.

For digital certificates, the Junos OS supports VeriSign, Entrust, Cisco Systems, and Microsoft Windows CAs for the Adaptive Services (AS) and Multiservices PICs.

To define digital certificates configuration for J Series Services Routers and AS and Multiservices PICs installed on M Series and T Series routers, include the following statements at the [edit security pki] hierarchy level:

The following tasks enable you to implement digital certificates on J Series Services Routers and AS and Multiservices PICs installed on M Series and T Series routers:

Configure the Certificate Authority Properties

A CA is a trusted third-party organization that creates, enrolls, validates, and revokes digital certificates.

To configure a certificate authority and its properties for the AS and Multiservices PICs, include the following statements at the [edit security pki] hierarchy level:

Tasks for configuring the Certificate Authority properties are:

Specify the CA Profile Name

The CA profile contains the name and URL of the CA or RA, as well as some retry-timer settings. CA certificates issued by Entrust, VeriSign, Cisco Systems, and Microsoft are compatible with the J Series Services Routers and AS and Multiservices PICs installed in the M Series and T Series routers.

To specify the CA profile name, include the ca-profile statement at the [edit security pki] security level:

You also need to specify the name of the CA identity used in the certificate request. This name is typically the domain name. To specify the name of the CA identity, include the ca-identity statement at the [edit security pki ca-profile ca-profile-name] level:

Specify an Enrollment URL

You specify the CA location where your router should send the SCEP-based certificate enrollment requests. To specify the CA location by naming the CA URL, include the url statement at the [edit security pki enrollment] hierarchy level:

url-name is the CA location. The format is http://CA_name, where CA_name is the CA host DNS name or IP address.

Specify the Enrollment Properties

You can specify the number of times a router will resend a certificate request and the amount of time, in seconds, the router should wait between enrollment attempts.

By default, the number of enrollment retries is set to 0, an infinite number of retries. To specify how many times a router will resend a certificate request, include the retry number-of-attempts statement at the [edit security pki ca-profile ca-profile-name enrollment] hierarchy level:

The range for number-of-attempts is from 0 through 100.

To specify the amount of time, in seconds, that a router should wait between enrollment attempts, include the retry-interval seconds statement at the [edit security pki ca-profile ca-profile-name enrollment] hierarchy level:

The range for seconds is from 0 through 3600.

Configure the Certificate Revocation List

Tasks to configure the certificate revocation list are:

Specify an LDAP URL

You can specify the URL for the Lightweight Directory Access Protocol (LDAP) server where your CA stores its current CRL. If the CA includes the Certificate Distribution Point (CDP) in the digital certificate, you do not need to specify a URL for the LDAP server. The CDP is a field within the certificate that contains information about how to retrieve the CRL for the certificate. The router uses this information to download the CRL automatically.

Configure an LDAP URL if you want to use a different CDP from the one specified in the certificate. Any LDAP URL you configure takes precedence over the CDP included in the certificate.

You can configure up to three URLs for each CA profile.

If the LDAP server requires a password to access the CRL, you need to include the password statement.

To configure the router to retrieve the CRL from the LDAP server, include the url statement and specify the URL name at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level:

url-name is the certificate authority LDAP server name. The format is ldap://server-name, where server-name is the CA host DNS name or IP address.

To specify to use a password to access the CRL, include the password statement at the [edit security pki ca-profile ca-profile-name revocation-check crl url] hierarchy level:

password is the secret password that the LDAP server requires for access.

Configure the Interval Between CRL Updates

By default, the time interval between CRL updates is 24 hours. To configure the amount of time between CRL updates, include the refresh-interval statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level:

The range for number of hours is from 0 through 8784.

Override Certificate Verification if CRL Download Fails

By default, if the router either cannot access the LDAP URL or retrieve a valid certificate revocation list, certificate verification fails and the IPsec tunnel is not established. To override this behavior and permit the authentication of the IPsec peer when the CRL is not downloaded, include the disable on-download-failure statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level:

Manage Digital Certificates

After you configure the CA profile, you can request a CA certificate from the trusted CA. Next, you must generate a public/private key pair. When the key pair is available, you can generate a local certificate either online or manually.

Tasks to manage digital certificates are:

Request a CA Digital Certificate for AS and Multiservices PICs installed on M Series and T Series Routers

For J Series Services Routers and AS and Multiservices PICs installed on M Series and T Series routers, issue the following command to obtain a digital certificate from a CA. Specify a configured ca-profile-name to request a CA certificate from the trusted CA.

For information about how to configure a CA profile, see Configure the Certificate Authority Properties.

In this example, the certificate is enrolled online and installed into the router automatically.

If you obtain the CA certificate directly from the CA (for example, as an e-mail attachment or Web site download), you can install it with the request security pki ca-certificate load command. For more information, see the CLI Explorer.

Generate a Public/Private Key Pair

After obtaining a certificate for an AS PIC or Multiservices PIC, you must generate a public-private key before you can generate a local certificate. The public key is included in the local digital certificate and the private key is used to decrypt data received from peers. To generate a public-private key pair, issue the request security pki generate-key-pair certificate-id certificate-id-name command.

The following example shows how to generate a public-private key for an AS PIC or Multiservices PIC:

Generate and Enroll a Local Digital Certificate

You can generate and enroll local digital certificates either online or manually. To generate and enroll a local certificate online by using the Simple Certificate Enrollment Protocol (SCEP) for an AS PIC or Multiservices PIC, issue the request security pki local-certificate enroll command. To generate a local certificate request manually in the PKCS-10 format, issue the request security pki generate-certificate-request command.

If you create the local certificate request manually, you must also load the certificate manually. To manually install a certificate in your router, issue the request security pki local-certificate load command.

The following example shows how to generate a local certificate request manually and send it to the CA for processing:

The trusted CA digitally signs the local certificate and returns it to you. Copy the certificate file into the router and load the certificate:

The name of the file sent to you by the CA might not match the name of the certificate identifier. However, the certificate-id name must always match the name of the key pair you generated for the router.

After the local and CA certificates have been loaded, you can reference them in your IPsec configuration. Using default values in the AS and Multiservices PICs, you do not need to configure an IPsec proposal or an IPsec policy. However, you must configure an IKE proposal that specifies the use of digital certificates, reference the IKE proposal and locate the certificate in an IKE policy, and apply the CA profile to the service set.

Configure Auto-Reenrollment of a Router Certificate

Use the auto-re-enrollment statement to configure automatic reenrollment of a specified existing router certificate before its existing expiration date. This function automatically reenrolls the router certificate. The reenrollment process requests the certificate authority (CA) to issue a new router certificate with a new expiration date. The date of auto-reenrollment is determined by the following parameters:

  • re-enroll-trigger-time—The percentage of the difference between the router certificate start date/time (when the certificate was generated) and the validity period; used to specify how long auto-reenrollment should be initiated before expiration.

  • validity-period—The number of days after issuance when the router certificate will expire, as set when a certificate is generated.

By default, this feature is not enabled unless configured explicitly. This means that a certificate that does not have auto-reenrollment configured will expire on its normal expiration date.

The ca-profile statement specifies which CA will be contacted to reenroll the expiring certificate. This is the CA that issued the original router certificate.

The challenge-password statement provides the issuing CA with the router certificate’s password, as set by the administrator and normally obtained from the SCEP enrollment Web page of the CA. The password is 16 characters in length.

Optionally, the router certificate key pair can be regenerated by using the re-generate-keypair statement.

To configure automatic reenrollment properties, include the following statements at the [edit security pki] hierarchy level:

percentage is the percentage for the reenroll trigger time. The range can be from 1 through 99 percent.

days is the number of days for the validity period. The range can be from 1 through 4095.

Tasks to configure automatic reenrollment of certificates are:

Specify the Certificate ID

Use the certificate-id statement to specify the name of the router certificate to configure for auto-reenrollment. To specify the certificate ID, include the statement at the [edit security pki auto-re-enrollment] hierarchy level:

Specify the CA Profile

Use the ca-profile statement to specify the name of the CA profile from the router certificate previously specified by certificate ID. To specify the CA profile, include the statement at the [edit security pki auto-re-enrollment certificate-id certificate-name] hierarchy level:

The referenced ca-profile must have an enrollment URL configured at the [edit security pki ca-profile ca-profile-name enrollment url] hierarchy level.

Specify the Challenge Password

The challenge password is used by the CA specified by the PKI certificate ID for reenrollment and revocation. To specify the challenge password, include the following statement at the [edit security pki auto-re-enrollment certificate-id certificate-name] hierarchy level:

Specify the Reenroll Trigger Time

Use the re-enroll-trigger-time statement to set the percentage of the validity period before expiration at which reenrollment occurs. To specify the reenroll trigger time, include the following statement at the [edit security pki auto-re-enrollment certificate-id certificate-name] hierarchy level:

percentage is the percentage for the reenroll trigger time. The range can be from 1 through 99 percent.

Specify the Regenerate Key Pair

When a regenerate key pair is configured, a new key pair is generated during reenrollment. On successful reenrollment, a new key pair and new certificate replace the old certificate and key pair. To generate a new key pair, include the following statement at the [edit security pki auto-re-enrollment certificate-id certificate-name] hierarchy level:

Specify the Validity Period

The validity-period statement specifies the router certificate validity period, in number of days, that the specified router certificate remains valid. To specify the validity period, include the statement at the [edit security pki auto-re-enrollment certificate-id certificate-name] hierarchy level:

days is the number of days for the validity period. The range can be from 1 through 4095.

See Also

  • Digital Certificates Overview
  • Configuring Digital Certificates for an ES PIC

Enroll a CA Certificate Using SCEP

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.

Enroll a CA Certificate Online Using 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.

Install a Digital Certificates on Your Router

A digital certificate is an electronic means for verifying your identity through a trusted third party, known as a certificate authority (CA). Alternatively, you can use a self-signed certificate to attest to your identity. The CA server you use can be owned and operated by an independent CA or by your own organization, in which case you become your own CA. If you use an independent CA, you must contact them for the addresses of their CA and certificate revocation list (CRL) servers (for obtaining certificates and CRLs) and for the information they require when submitting personal certificate requests. When you are your own CA, you determine this information yourself. The Public Key Infrastructure (PKI) provides an infrastructure for digital certificate management.

Request a Digital Certificate—Manual Process

To obtain digital certificates manually, you must configure a CA profile, generate a private-public key pair, create a local certificate, and load the certificates on the router. After loading the certificates, they can be referenced in your IPsec-VPN configuration.

This procedure shows how you can configure a CA profile:

  1. Configure a CA profile:

    After you commit this configuration. The configuration on Router 2 must contain the following:

  2. Certificate revocation list (CRL) verification is enabled by default. You can optionally specify the Lightweight Access Directory (LDAP) server where the CA stores the CRL. The certificate typically includes a certificate distribution point (CDP), which contains information about how to retrieve the CRL for the certificate. The router uses this information to download the CRL automatically. In this example, the LDAP URL is specified, which overrides the location provided in the certificate:

    After you commit this configuration. The configuration on Router 2 must contain the following:

  3. After you configure the CA profile, request a CA certificate from the trusted CA. In this example, the certificate is enrolled online and installed into the router automatically.

    If you obtain the CA certificate directly from the CA (for example, as an e-mail attachment or website download), you can install it with the request security pki ca-certificate load command.

  4. Next, you must generate a private-public key pair before you can create a local certificate.

    When the key pair is available, generate a local certificate request and send it to the CA for processing.

    You can request the creation and installation of a local certificate online with the request security pki local-certificate enroll command.

  5. The trusted CA digitally signs the local certificate and returns it to you. Copy the certificate file into the router and load the certificate.

    The name of the file sent to you by the CA might not match the name of the certificate identifier. However, the certificate-id name must always match the name of the key pair you generated for the router.

Understand ACME Protocol

Learn about ACME protocol and how to enroll the certificate.

What is ACME Protocol

Automated Certificate Management Environment (ACME) protocol is a new PKI enrollment standard used by several PKI servers such as Let’s Encrypt. The Let’s encrypt certificate allows for free usage of Web server certificates in SRX Series Firewalls, and this can be used in Juniper Secure Connect and J-Web. The Junos OS automatically re-enroll Let’s Encrypt certificates on occurrence of every 25 days.

The ACME protocol allows the enrollment of certificates from Let’s Encrypt server or ACME enabled servers. The SRX Series Firewalls enrolls the certificates from Let’s Encrypt server and Juniper Secure Connect validates the certificates without copying and downloading any CA certificates.

When using Let’s Encrypt, ensure that the Let’s Encrypt server is able to resolve the domain name to the IP address of the SRX Series Firewall interface as shown in Figure 2. It must be able to reach the SRX Series Firewall interface on TCP port 80. During the certificate enrollment, the SRX Series Firewall will temporarily allow this incoming request automatically. If your SRX Series Firewall or an intermediate firewall or a router is blocking the TCP port 80, certificate enrollment will fail.

Figure 2: Name Resolution for Let's EncryptName Resolution for Let's Encrypt

Limitations

  • ACME specification - The dns-01 and external account binding are not supported.

  • ACME cannot be used when J-Web listen to port 80

  • Wildcard certificate is not supported such as *.mydomain.com, instead you can enroll multiple dns names.

Enroll Local Certificate Using Let’s Encrypt Server

This example shows how to enroll the local certificate using Let's Encrypt.

  1. Specify the CA profile.

  2. Commit the configuration.

  3. Load the CA certificate.

    To download the ISRG_Root_X1.pem certificate, see KB84991.

  4. Create ACME key ID.

  5. Preparing enrollment of local certificate.

  6. Enroll a certificate with one domain name.

    Enroll a certificate with multiple domain names.

  7. Once the enrollment is finished the issued certificate will be loaded in certificate-id service-mydomian.

Manual Re-Enroll Local Certificate

To re-enroll a local certificate online:

  1. Initiate the re-enrollment request.

  2. Once the re-enrollment is finished the issued certificate will be loaded in certificate-id service-mydomian.

Delete ACME Account

To delete the ACME account:

  1. Delete the ACME account.

    You can delete the ACME account key only if the ACME is activated or created by the enrollment.

Platform-Specific SSL Termination Services Behavior

Use Feature Explorer to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform:

Platform Difference
SRX Series

  • SRX5400, SRX5600, and SRX5800 support the SSL termination services.