Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Certificate Life Cycle Management Overview

The general life cycle for certificates includes the following phases:

  1. Generation of public/private keys, identity information, and certificate request

  2. Enrollment (request and retrieval)

  3. Usage within Internet Key Exchange (IKE)

  4. Certificate validation and revocation checks

  5. Certificate renewal

Details on each phase of the certificate life cycle are given in the following topics:

Generation of Public/Private Keys, Identity Information, and Certificate Request

The private key on a device must be generated on that device, and it should never be viewed or saved from that device. The user identity and private key form the basis of the certificate request and will continue to be used with the local certificate after enrollment. Therefore it is important to match the certificate-ID of the keys that are generated with the proper certificate request and eventually with the local certificate. The certificate request is available in PKCS10 format; the certificate request must be sent to the certificate authority (CA) either through an e-mail or some sort of web-based front-end site.

Certificate Enrollment

Junos OS Release 8.5 and earlier supports only manual certificate requests. This process includes generation of a PKCS10 request, submission to the certificate authority (CA), retrieval of the signed certificate, and manually loading of the certificate into the Junos OS device as the local certificate.

Automatic sending of certificate requests through Simple Certificate Enrollment Protocol (SCEP) is supported only in Junos OS Release 9.0 and later. For more information, see Appendix D: Simple Certificate Enrollment Protocol.

Certificate Identity Usage Within IKE

During the Internet Key Exchange (IKE) Phase 1 setup, a certificate can identify the peer by:

  • IP address

  • Fully qualified domain name (FQDN) (domain name)

  • User fully qualified domain name (U-FQDN) (e-mail address)

  • DN (distinguished name)

Most virtual private network (VPN) administrators use an IP address or FQDN for a VPN gateway identity type and use an e-mail address (U-FQDN) for a NetScreen-Remote (NSR) Client VPN laptop/user’s identity type. The IKE IDs are added into the SubjectAlternativeName (a v3 extension) field of the certificate.

Note:

If the IP address of the VPN peer changes, then a new certificate must be issued with the new IP address, and the old certificate should be revoked.

If the certificate authority (CA) does not support the signing of certificates with a SubjectAlternativeName field, then you must use the DN as the IKE ID on the Junos OS device or NSR configurations.

You must specify one of the following as the IKE ID in the certificate request:

  • IP address

  • Domain name

  • E-mail address

Certificate Validation and Revocation Checking

Junos OS supports revocation checking by using the certificate revocation list (CRL) lookup method. The CRL can either be manually loaded in the Junos OS device or automatically retried online from the CRL Distribution Point (CDP), or it can be loaded on demand through Lightweight Directory Access Protocol (LDAP) or HTTP. Junos OS supports both DER and Privacy-Enhanced Mail (PEM) formats for CRL.

Note:

Junos OS does not support the Online Certificate Status Protocol (OCSP) method, which is a more scalable system than CRLs and CDP. Many other CAs also do not support an OCSP interface.

Certificate Renewal

The certificate renewal process is similar to the initial certificate enrollment process. The renewal process includes replacing an old certificate (about to expire) on the virtual private network (VPN) device with a new certificate.

Currently the Junos OS supports only the manual renewal process. The Simple Certificate Enrollment Protocol (SCEP) can be used to re-enroll the local certificates automatically before they expire. For more information, see Appendix D: Simple Certificate Enrollment Protocol.