Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Revoking Digital Certificates

 

Digital certificates have an expiration date, however, prior to expiration, a certificate may no longer be valid due to many reasons. You can manage certificate revocations and validations locally and by referencing a Certificate Authority (CA) certificate revocation list (CRL).

Understanding Online Certificate Status Protocol and Certificate Revocation Lists

OCSP is used to check the revocation status of X509 certificates. OCSP provides revocation status on certificates in real time and is useful in time-sensitive situations such as bank transactions and stock trades.

The revocation status of a certificate is checked by sending a request to an OCSP server that resides outside of an SRX Series device. Based on the response from the server, the VPN connection is allowed or denied. OCSP responses are not cached on SRX Series devices.

The OCSP server can be the certificate authority (CA) that issues a certificate or a designated authorized responder. The location of the OCSP server can be configured manually or extracted from the certificate that is being verified. Requests are sent first to OCSP server locations that are manually configured in CA profiles with the ocsp url statement at the [edit security pki ca-profile profile-name revocation-check] hierarchy level; up to two locations can be configured for each CA profile. If the first configured OCSP server is not reachable, the request is sent to the second OCSP server. If the second OCSP server is not reachable, the request is then sent to the location in the certificate's AuthorityInfoAccess extension field. The use-ocsp option must also be configured, as certificate revocation list (CRL) is the default checking method.

SRX Series devices accept only signed OCSP responses from the CA or authorized responder. The response received is validated using trusted certificates. The response is validated as follows:

  1. The CA certificate enrolled for the configured CA profile is used to validate the response.
  2. The OCSP response might contain a certificate to validate the OCSP response. The received certificate must be signed by a CA certificate enrolled in the SRX Series device. After the received certificate is validated by the CA certificate, it is used to validate the OCSP response.

The response from the OCSP server can be signed by different CAs. The following scenarios are supported:

  • The CA server that issues the end entity certificate for a device also signs the OCSP revocation status response. The SRX Series device verifies the OCSP response signature using the CA certificate enrolled in the SRX Series device. After the OCSP response is validated, the certificate revocation status is checked.

  • An authorized responder signs the OCSP revocation status response. The certificate for the authorized responder and the end entity certificate being verified must be issued by the same CA. The authorized responder is first verified using the CA certificate enrolled in the SRX Series device. The OCSP response is validated using the responder’s CA certificate. The SRX Series device then uses the OCSP response to check the revocation status of the end entity certificate.

  • There are different CA signers for the end entity certificate being verified and the OCSP response. The OCSP response is signed by a CA in the certificate chain for the end entity certificate being verified. (All peers participating in an IKE negotiation need to have at least one common trusted CA in their respective certificate chains.) The OCSP responder’s CA is verified using a CA in the certificate chain. After validating the responder CA certificate, the OCSP response is validated using the responder’s CA certificate.

To prevent replay attacks, a nonce payload can be sent in an OCSP request. Nonce payloads are sent by default unless it is explicitly disabled. If enabled, the SRX Series device expects the OCSP response to contain a nonce payload, otherwise the revocation check fails. If OCSP responders are not capable of responding with a nonce payload, then the nonce payload must be disabled on the SRX Series device.

In the normal course of business, certificates are revoked for various reasons. You might wish to revoke a certificate if you suspect that it has been compromised, for example, or when a certificate holder leaves the company.

You can manage certificate revocations and validations in two ways:

  • Locally— This is a limited solution.

  • By referencing a Certificate Authority (CA) certificate revocation list (CRL)— You can automatically access the CRL online at intervals you specify or at the default interval set by the CA.

In Phase 1 negotiations, participants check the CRL list to see if certificates received during an IKE exchange are still valid. If a CRL did not accompany a CA certificate and is not loaded on the device, the device tries to download it automatically from the CRL distribution point of the local certificate. If the device fails to connect to the URL in the certificate distribution point (CDP), it tries to retrieve the CRL from the URL configured in the CA profile.

If the certificate does not contain a certificate distribution point extension, and you cannot automatically retrieve the CRL through Lightweight Directory Access Protocol (LDAP) or Hypertext Transfer Protocol (HTTP), you can retrieve a CRL manually and load that in the device.

Local certificates are being validated against certificate revocation list (CRL) even when CRL check is disabled. This can be stopped by disabling the CRL check through the Public Key Infrastructure (PKI) configuration. When CRL check is disabled, PKI will not validate local certificate against CRL.

Comparison of Online Certificate Status Protocol and Certificate Revocation List

Online Certificate Status Protocol (OCSP) and certificate revocation list (CRL) can both be used to check the revocation status of a certificate. There are advantages and disadvantages to each method.

  • OCSP provides certificate status in real time, while CRL uses cached data. For time-sensitive applications, OCSP is the preferred approach.

  • CRL checking is faster because lookup for certificate status is done on information cached on the VPN device. OCSP requires time to obtain the revocation status from an external server.

  • CRL requires additional memory to store the revocation list received from a CRL server. OCSP does not require additional memory to save the revocation status of certificates.

  • OCSP requires that the OCSP server be available at all times. CRL can use cached data to check the revocation status of certificates when the server is unreachable.

Note

On MX Series and SRX Series devices, CRL is the default method used to check the revocation status of a certificate.

Improving Security by Configuring OCSP for Certificate Revocation Status

This example shows how to improve security by configuring two peers using the Online Certificate Status Protocol (OCSP) to check the revocation status of the certificates used in Phase 1 negotiations for the IPsec VPN tunnel.

Requirements

On each device:

  • Obtain and enroll a local certificate. This can be done either manually or by using the Simple Certificate Enrollment Protocol (SCEP).

  • Optionally, enable automatic renewal of the local certificate.

  • Configure security policies to permit traffic to and from the peer device.

Overview

On both peers, a certificate authority (CA) profile OCSP-ROOT is configured with the following options:

  • CA name is OCSP-ROOT.

  • Enrollment URL is http://10.1.1.1:8080/scep/OCSP-ROOT/. This is the URL where SCEP requests to the CA are sent.

  • The URL for the OCSP server is http://10.157.88.56:8210/OCSP-ROOT/.

  • OCSP is used first to check the certificate revocation status. If there is no response from the OCSP server, then the certificate revocation list (CRL) is used to check the status. The CRL URL is http://10.1.1.1:8080/crl-as-der/currentcrl-45.crlid=45.

  • The CA certificate received in an OCSP response is not checked for certificate revocation. Certificates received in an OCSP response generally have shorter lifetimes and a revocation check is not required.

Table 1 shows the Phase 1 options used in this example.

Table 1: Phase 1 Options for OCSP Configuration Example

Option

Peer A

Peer B

IKE proposal

ike_prop

ike_prop

Authentication method

RSA signatures

RSA signatures

DH group

group2

group2

Authentication algorithm

SHA 1

SHA 1

Encryption algorithm

3DES CBC

3DES CBC

IKE policy

ike_policy

ike_policy

Mode

aggressive

aggressive

Proposal

ike_prop

ike_prop

Certificate

local-certificate localcert1

local-certificate localcert1

IKE gateway

jsr_gateway

jsr_gateway

Policy

ike_policy

ike_policy

Gateway address

198.51.100.50

192.0.2.50

Remote identity

localcert11.example.net

-

Local identity

-

localcert11.example.net

External interface

reth1

ge-0/0/2.0

Version

v2

v2

Table 2 shows the Phase 2 options used in this example.

Table 2: Phase 2 Options for OCSP Configuration Example

Option

Peer A

Peer B

IPsec proposal

ipsec_prop

ipsec_prop

Protocol

ESP

ESP

Authentication algorithm

HMAC SHA1-96

HMAC SHA1-96

Encryption algorithm

3DES CBC

3DES CBC

Lifetime seconds

1200

1200

Lifetime kilobytes

150,000

150,000

IPsec policy

ipsec_policy

ipsec_policy

PFC keys

group2

group2

Proposal

ipsec_prop

ipsec_prop

VPN

test_vpn

test_vpn

Bind interface

st0.1

st0.1

IKE gateway

jsr_gateway

jsr_gateway

Policy

ipsec_policy

ipsec_policy

Establish tunnels

-

immediately

Topology

Figure 1 shows the peer devices that are configured in this example.

Figure 1: OCSP Configuration Example
 OCSP Configuration
Example

Configuration

Configuring Peer A

CLI Quick Configuration

To quickly configure VPN peer A to use OCSP, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure VPN peer A to use OCSP:

  1. Configure interfaces.
  2. Configure the CA profile.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security pki ca-profile OCSP-ROOT, show security ike, and show security ipsec commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Configuring Peer B

CLI Quick Configuration

To quickly configure VPN peer B to use OCSP, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure VPN peer B to use OCSP:

  1. Configure interfaces.
  2. Configure the CA profile.
  3. Configure Phase 1 options.
  4. Configure Phase 2 options.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security pki ca-profile OCSP-ROOT, show security ike, and show security ipsec commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying CA Certificates

Purpose

Verify the validity of a CA certificate on each peer device.

Action

From operational mode, enter the show security pki ca-certificate ca-profile OCSP-ROOT or show security pki ca-certificate ca-profile OCSP-ROOT detail command.

Note

In this example, IP addresses are used in the URLs in the CA profile configuration. If IP addresses are not used with CA-issued certificates or CA certificates, DNS must be configured in the device’s configuration. DNS must be able to resolve the host in the distribution CRL and in the CA URL in the CA profile configuration. Additionally, you must have network reachability to the same host to receive revocation checks.

Meaning

The output shows the details and validity of CA certificate on each peer as follows:

  • C—Country.

  • O—Organization.

  • CN—Common name.

  • Not before—Begin date of validity.

  • Not after—End date of validity.

Verifying Local Certificates

Purpose

Verify the validity of a local certificate on each peer device.

Action

From operational mode, enter the show security pki local-certificate certificate-id localcert1 detail command.

Meaning

The output shows the details and validity of a local certificate on each peer as follows:

  • DC—Domain component.

  • CN—Common name.

  • OU—Organizational unit.

  • O—Organization.

  • L—Locality

  • ST—State.

  • C—Country.

  • Not before—Begin date of validity.

  • Not after—End date of validity.

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status on each peer device.

Action

From operational mode, enter the show security ike security-associations command.

From operational mode, enter the show security ike security-associations detail command.

Meaning

The flags field in the output shows that, IKE security association is created.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status on each peer device.

Action

From operational mode, enter the show security ipsec security-associations command.

From operational mode, enter the show security ipsec security-associations detail command.

Meaning

The output shows the ipsec security associations details.

Example: Manually Loading a CRL onto the Device

This example shows how to load a CRL manually onto the device.

Requirements

Before you begin:

  1. Generate a public and private key pair. See Example: Generating a Public-Private Key Pair.

  2. Generate a certificate request. See Example: Manually Generating a CSR for the Local Certificate and Sending It to the CA Server.

  3. Configure a certificate authority (CA) profile. See Example: Configuring a CA Profile.

  4. Load your certificate onto the device. See Example: Loading CA and Local Certificates Manually.

Overview

You can load a CRL manually, or you can have the device load it automatically, when you verify certificate validity. To load a CRL manually, you obtain the CRL from a CA and transfer it to the device (for example, using FTP).

In this example, you load a CRL certificate called revoke.crl from the /var/tmp directory on the device. The CA profile is called ca-profile-ipsec. (Maximum file size is 5 MB.)

Note

If a CRL is already loaded into the ca-profile the command clear security pki crl ca-profile ca-profile-ipsec must be run first to clear the old CRL.

Configuration

Step-by-Step Procedure

To load a CRL certificate manually:

  1. Load a CRL certificate.
    Note

    Junos OS supports loading of CA certificates in X509, PKCS #7, DER, or PEM formats.

Verification

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

Understanding Dynamic CRL Download and Checking

Digital certificates are issued for a set period of time and are invalid after the specified expiration date. A CA can revoke an issued certificate by listing it in a certificate revocation list (CRL). During peer certificate validation, the revocation status of a peer certificate is checked by downloading the CRL from a CA server to the local device.

A VPN device must be able to check a peer’s certificate for its revocation status. A device can use the CA certificate received from its peer to extract the URL to dynamically download the CA’s CRL and check the revocation status of the peer’s certificate. A dynamic CA profile is automatically created on the local device with the format dynamic-nnn. A dynamic CA profile allows the local device to download the CRL from the peer’s CA and check the revocation status of the peer’s certificate. In Figure 2, Host-A can use the Sales-CA and EE certificates received from Host-B to dynamically download the CRL for Sales-CA and check the revocation status of Host-B’s certificate.

Figure 2: Multilevel Hierarchy for Certificate-Based Authentication
 Multilevel
Hierarchy for Certificate-Based Authentication

To enable dynamic CA profiles, the revocation-check crl option must be configured on a parent CA profile at the [edit security pki ca-profile profile-name] hierarchy level.

The revocation check properties of a parent CA profile are inherited for dynamic CA profiles. In Figure 2, the CA profile configuration on Host-A for Root-CA enables dynamic CA profiles as shown in the following output:

A dynamic CA profile is created on Host-A for Sales-CA. Revocation checking is inherited for the Sales-CA dynamic CA profile from Root-CA.

If the revocation-check disable statement is configured in a parent CA profile, dynamic CA profiles are not created and dynamic CRL download and checking is not performed.

The data for CRLs downloaded from dynamic CA profiles are displayed with the show security pki crl command in the same way as CRLs downloaded by configured CA profiles. The CRL from a dynamic CA profile is updated periodically as are those for CA profiles that are configured in the device.

Note

The CA certificate is required to validate the CRL received from a CA server; therefore, the CA certificate received from a peer is stored on the local device. Because the CA certificate is not enrolled by an administrator, it is used only for validating the CRL received from the CA server and not for validating the peer certificate.

Example: Configuring a Certificate Authority Profile with CRL Locations

This example shows how to configure a certificate authority profile with CRL locations.

Requirements

Before you begin:

  1. Generate a key pair in the device. See Example: Generating a Public-Private Key Pair.

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

  3. Obtain a personal certificate from the CA. See Example: Manually Generating a CSR for the Local Certificate and Sending It to the CA Server.

  4. Load the certificate onto the device. See Example: Loading CA and Local Certificates Manually.

  5. Configure automatic reenrollment. See Example: Configuring SecurID User Authentication.

  6. If necessary, load the certificate's CRL on the device. See Example: Manually Loading a CRL onto the Device.

Overview

In Phase 1 negotiations, you check the CRL list to see if the certificate that you received during an IKE exchange is still valid. If a CRL did not accompany a CA certificate and is not loaded on the device, Junos OS tries to retrieve the CRL through the LDAP or HTTP CRL location defined within the CA certificate itself. If no URL address is defined in the CA certificate, the device uses the URL of the server that you define for that CA certificate. If you do not define a CRL URL for a particular CA certificate, the device gets the CRL from the URL in the CA profile configuration.

Note

The CRL distribution point extension (.cdp) in an X509 certificate can be added to either an HTTP URL or an LDAP URL.

In this example, you direct the device to check the validity of the CA profile called my_profile and, if a CRL did not accompany a CA certificate and is not loaded on the device, to retrieve the CRL from the URL http://abc/abc-crl.crl.

Configuration

Step-by-Step Procedure

To configure certificate using CRL:

  1. Specify the CA profile and URL.
  2. If you are done configuring the device, commit the configuration.

Verification

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

Example: Verifying Certificate Validity

This example shows how to verify the validity of a certificate.

Requirements

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you verify certificates manually to find out whether a certificate has been revoked or whether the CA certificate used to create a local certificate is no longer present on the device.

When you verify certificates manually, the device uses the CA certificate (ca-cert) to verify the local certificate ( local.cert). If the local certificate is valid, and if revocation-check is enabled in the CA profile, the device verifies that the CRL is loaded and valid. If the CRL is not loaded and valid, the device downloads the new CRL.

For CA-issued certificates or CA certificates, a DNS must be configured in the device’s configuration. The DNS must be able to resolve the host in the distribution CRL and in the CA cert/revocation list url in the ca-profile configuration. Additionally, you must have network reachability to the same host in order for the checks to receive.

Configuration

Step-by-Step Procedure

To manually verify the validity of a certificate:

  1. Verify the validity of a local certificate.
  2. Verify the validity of a CA certificate.
    Note

    The associated private key and the signature are also verified.

Verification

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

Note

If an error is returned instead of a positive verification the failure is logged in pkid.

Deleting a Loaded CRL (CLI Procedure)

You can choose to delete a loaded CRL if you no longer need to use it to manage certificate revocations and validation.

Use the following command to delete a loaded certificate revocation list:

Specify a CA profile to delete a CRL associated with the CA identified by the profile, or use all to delete all CRLs.