Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Certificate Administration Overview

This topic includes the following sections:

Overview on Usage of SSL and IPsec/IKE Methods

Currently, the Junos OS supports only the IP Security/Internet Key Exchange (IPsec/IKE ) method for using certificates for public key validation and identity binding.

Table 1 compares the authentication using the SSL method and IPsec/IKE method.

Table 1: Certificate Authentication Process (SSL and IPsec/IKE)

SSL Implementation

IPsec/IKE Implementation

Process is one-sided and simple.

Process is bidirectional and uses certificates.

The security device acts as an SSL server, and the administrator’s web browser (or for webauth, the user’s web browser) acts as the SSL client.

Each VPN device sends its certificate to the other device.

The security device sends a certificate to the web browser for identification, and the web browser starts a secured SSL session.

Each IPsec device validates the other device’s certificate using the certificate authority (CA) certificate.

The security device authenticates the user or administrator through a login and password (secured with SSL encryption).

The security device checks the other device’s certificate through a certificate revocation list (CRL) to see whether it has been revoked.

The security device does not require a user-based SSL certificate from the web browser and does not need CA and CRLs loaded on it.

The minimum PKI elements required to use certificate-based authentication are; a local certificate, a CA certificate, and the CA’s CRL.

Process for Setting Up the PKI Elements

The minimum public key infrastructure (PKI) elements required for certificate-based authentication in Junos OS are a local certificate, certificate authority (CA) certificate, and the CA’s certificate revocation list (CRL).

To manually load a local certificate, a CA certificate, and the CA CRL on the device:

  1. Configure the basic settings of the device as required by PKI:

    1. Set the accurate clock, date, time zone, and daylight savings.

    2. Set Domain Name System (DNS) to resolve hostnames that may be used in certificates and for CRL distribution points (CDPs).

    3. Set Network Time Protocol (NTP) to maintain accurate clocking because certificates have lifetimes based on a specific date and time.

  2. Create a CA-profile for the certificate request and enrollment process.

  3. Generate the certificate request (p10 file) and save it to a local file system or send it through an e-mail.

  4. Submit the p10 file to the CA (through a Web server that acts as the front-end of the CA. Note that an open SSL CA supports only the command-line interface).

  5. Retrieve the CA certificate (through the CA web server front-end interface).

  6. Retrieve the Junos OS device’s new local certificate after the CA has verified it (usually through the CA web server front-end interface).

  7. Retrieve the CA CRL (through a pre-specified URL to the CA web server).

  8. Load the CA certificate, local certificate, and CRL onto the Junos OS device.

  9. Define the IKE policy and gateway to use the RSA-Signature authentication method (as opposed to pre-shared keys) and the local and CA certificates.

Note:

The disadvantage of manual uploading of the certificates and CRLs is the extra time and effort needed to maintain an up-to-date CRL on all the devices.

Alternatively, you can define a CDP for the Junos OS device to retrieve the latest CRLs automatically. Most CAs have the CDP defined in the CA certificate itself, which the Junos OS device can use automatically. You can also define the CDP in the CA profile configuration.

For more information on certificates, see the Junos OS documentation at https://www.juniper.net/documentation/software/junos/.

Choosing the IKE Identity to Use in the VPN and the Certificate

Junos OS supports the following four Internet Key Exchange (IKE) ID types that virtual private network (VPN) gateways can use to identify each other:

  • IP address (example: 2.2.2.2)

  • Fully qualified domain name (FQDN ) (example: vpn1.juniper.net)

  • User-fully qualified domain name (U-FQDN ) or e-mail address (example: johndoe@juniper.net)

  • Distinguished name (DN) (example: CN=John Doe, OU=sales, O=Juniper Networks, C=US)

Note:

When configuring pre-shared keys, only the IP address, FQDN, and U-FQDN/e-mail address are used.

If you use an IP address, FQDN, or U-FQDN/e-mail address as the IKE ID type, then it:

  • Must be defined in the SubjectAlternativeName field of the certificate

  • Should match the peer configuration in the security ike gateway <gateway-name> hierarchy

You must define at least one IP address, FQDN, or U-FQDN/e-mail address when you generate a certificate request.

If your certificates do not have a SubjectAlternativeName field, then you should use DN for the IKE ID. To use DN, you have to define a distinguished name in dynamic IKE configuration by specifying a container (the DN must match exactly) or a wildcard (only a portion of the DN needs to match).

The following are the differences between the container method and the wildcard method:

  • If the container keyword is used, then all the DN values specified must exactly match the values in the received certificate. In addition, the ordering of the values in both the remote certificate received and the gateway definition must match.

  • If the wildcard keyword is used, then any one of the DN values specified must match a DN value in the received certificate. The ordering of the values in the remote certificate received and in the gateway definition can be different. The Junos OS device analyzes and compares only the defined DN fields; any unspecified DN fields are ignored.

Note:

If the certificate is using multiple fields of the same type (example: OU=sales, OU=engr, OU=central), then you must use the container method and ensure that the DN fields are defined exactly as they are received by the remote peer.

Certificate Validation During the IKE Phase 1 Setup

During Internet Key Exchange (IKE), when two VPN peers are establishing a tunnel, each VPN device receives a certificate from the other IKE peer. On receiving the certificates, the device completes following tasks:

  1. Pulls the IKE ID (defined in IKE Phase 1) from the peer and searches for the matching IKE definition on the gateway.

  2. Validates the certificate by verifying the digital signature on the remote device certificate using the public key in the certificate authority (CA) certificate.

  3. Validates the current time mentioned in certificates in “Valid from” and “Valid to” fields.

  4. Validates that the certificate contains the identity for the remote peer.

  5. Performs the revocation check (unless revocation check is disabled) on the certificate to ensure that the certificate serial number is not in the CA certificate revocation list (CRL). This may cause the Junos OS device to automatically retrieve a new CRL from the CDP.

When all certificate checks are completed successfully, then IKE continues with the tunnel setup.

Note:

Unless explicitly disabled in the configuration, CRLs are checked whenever the Junos OS device receives a certificate for a remote VPN gateway. If the CRL is not manually loaded, then the system may:

  • Load the CRL from the CRL distribution point (CDP) defined in the certificate. Junos OS devices support HTTP and Lightweight Directory Access Protocol (LDAP) for CDPs.

  • If the CDP is not available in the certificate, then the Junos OS device checks for a CDP setting in the CA profile.

  • Use the global or default CDP (if already configured).

When verifying a certificate, a certificate chain is formed from the following:

  • Remote server local certificate

  • Optional certificate chain from the IKE peer

  • Locally stored CA certificates

Any CA certificate loaded from local storage during boot are considered as “trusted” certificates. The Junos OS supports certificate path validation upward through as many as seven levels of CA authorities in the hierarchy.

Junos OS currently supports only “partial” certificate path validation. Unlike “full” certificate path validation, “partial” validation does not require that the last certificate in the certificate chain be a root CA certificate (a self-signed CA). With "partial" certificate path validation, the last certificate can be a non-root CA certificate. However, the last certificate in the validation chain must be from local storage.

Unsupported PKI Protocols in Junos OS

Junos OS does not support the following public key infrastructure (PKI) protocols, which are primarily alternative forms of management protocols for communication between CAs and entities that use certificates:

  • CMC—Certificate Management of Messages over CMS defined in RFC 2797.

    CMC is endorsed by Microsoft and VeriSign, but has limited support from other products.

  • CMP—Certificate Management Protocol defined in RFC 2510.

    CMP is endorsed by Entrust, Baltimore, SSH, RSA, and OpenSSL. Even though this protocol works, it has limited deployment and interoperability with other interfaces from different vendors.

  • XKMS—XML Key Management Specifications are defined in http://www.w3.org/TR/xkms/.

    XKMS is a relatively new protocol and currently not supported by Juniper Networks.

Related Documentation