Public key infrastructure

SR OS PKI implementation supports the following features:

• Supported public key algorithm: RSA/DSA/ECDSA:

• Certificate enrollment includes:

  • Locally generated RSA/DSA/ECDSA key

  • Off-line enrollment via PKCS#10

  • On-line enrollment via Certificate Management Protocol version 2 (CMPv2)

  • On-line enrollment via Enrollment over Secure Transport Protocol (EST)

• Support CA chain

• Certificate revocation check:

  • CRL for both EE (End Entity) and CA certificate

  • OCSP for EE certificate only

The SR OS requires the following objects to be stored locally as file:

• CA Certificate

• CRL

• System’s own certificate

• System’s own key

All above objects must be imported before they can be used by the SR OS. This is performed by using the admin certificate import command. The import process converts the format of input file to DER, encrypts it and saves it in cf3:/system-pki directory.

The imported file can also be exported as one to use in the specified format by means of the admin certificate export command.

The admin certificate import and admin certificate export command supports following formats:

• Certificates can be import/export by using following formats:

  • PKCS#12

  • PKCS#7 (DER and PEM)

  • PEM

  • DER

  If there are multiple certificates in the file, only the first one is used.

• Key pair can be import/export by using following formats:

  • PKCS#12 (must along with certificate)

  • PEM

  • DER

• CRL can be import/export by using following formats:

  • PKCS#7 (DER and PEM)

  • PEM

  • DER

• PKCS#12 file can be encrypted with a password.

In SR OS, CA-related configuration is stored in a CA-profile which contains following configurations:

• name and description

• CA’s certificate (an imported certificate)

• CA’s CRL (an imported CRL)

• revocation check method (specifies the way CA checks the revocation status of the certificate it issued)

• CMPv2 (a CMPv2 server related configurations)

• OCSP (an OCSP responder related configurations)

When user enables a ca-profile (no shutdown), the system loads the specified CA certificate and CRL into memory. And following checks are performed:

• for CA certificate

  • All non-optional fields defined in section 4.1 of RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, must exist and conform to the RFC 5280 defined format.

  • Check the version field to see if its value is 0x2.

  • Check the Validity field to see that if the certificate is still in validity period.

  • X509 Basic Constraints extension must exist and CA Boolean must be True.

  • If Key Usage extension exists, then at least keyCertSign and cRLSign should be asserted.

• for CRL

  • All non-optional fields defined in section 5.1 of RFC 5280 must exist and conform to the RFC 5280 defined format.

  • If the version field exists, the value must be 0x1.

  • The delta CRL Indicator must not exist (Delta CRL is not supported).

  • CRL must be signed by the configured CA certificate.

CRL, by default, is required to enable ca-profile, but it could be optional by changing the revocation check method configuration. For the revocation check method configuration, see Certificate revocation check.

In case of verifying a certificate with a CA or a chain of CAs, the system needs to identify the issuer CA of the certificate in question. The SR OS looks through all configured ca-profiles to find the issuer CA. The following is the method system used to find the issuer CA:

• The issuer CA’s certificate subject must match the issuer field of the certificate in question.

• If present, the authority key identifier of the certificate in question must match the subject key identifier of the issuer CA’s certificate.

• If present, the key usage extension of the issuer CA’s certificate must permit certificate signing.

The SR OS supports two certificate enrollment methods:

• off-line method via PKCS#10

• on-line method via CMPv2

• on-line method via EST

The off-line method works as follows:

1. Generate a key pair via the command admin certificate gen-keypair

   For example:

   admin certificate gen-keypair cf3:/segw.key size 2048 type rsa

2. Generate a PKCS#10 certificate signing request with the key generated in the step mentioned above via the admin certificate gen-local-cert-req command.

   For example:

   admin certificate gen-local-cert-req keypair cf3:/segw.key subject-dn

   C=US,ST=CA,O=ALU,CN=SeGW domain-name segw-1.alu.com file cf3:/segw.pkcs10

   The user specifies the subject of certificate request and optionally can also specify a FQDN or an IP address as SubjectAltName.

3. Import the key file via the admin certificate import command.

   For example:

   admin certificate import type key input cf3:/segw.key output segw.key format de

4. Because the key is imported, remove the key file generated in the first step for security reasons.

5. Send the PKCS#10 file to CA via an offline method such as email.

6. CA signs the request, and returns the certificate.

7. Import the result certificate the admin certificate import command.

   For example:

   admin certificate import type cert input cf3:/segw.cert output segw.cert format pem

For CMPv2-based enrollment, see CMPv2. For EST-based enrollment, see Enrollment over secure transport.

A revocation check is a process to see if a certificate has been revoked by the issuer CA.

The SR OS supports two methods for certificate revocation check:

• CRL

• OCSP

CRL can be used for both EE and CA certificate checks, while OCSP could only be used for an EE certificate.

The use of a revocation check for an EE certificate is application-specific. With an IPsec application, users can configure multiple check methods with a priority order for an EE certificate. With the status-verify command in the ipsec-gw/ipsec-tunnel configuration context, a primary method, a secondary method and a default result can be configured. The primary and secondary method can be either OCSP or CRL. The default result is either good or revoked. If the system cannot get an answer from the primary method, then it falls back to the secondary method. If secondary method also does not return an answer, then the system uses the default result.

By default, the system uses CRL to check the revocation status of a certificate, whether it is an end entity certificate or a CA certificate. This makes CRL a mandatory configuration in the ca-profile.

The revocation-check command in the ca-profile can change this behavior, with revocation-check crl-optional configured:

When a user enables the ca-profile (no shutdown), the system tries to load the configured CRL (specified by the crl-file command). But, if the system fails to load it for following reasons, then the system still keeps ca-profile oper-up, but treat the CRL as non-existent.

• The CRL file does not exist.

• The CRL is not properly encoded, possibly because of an interrupted file transfer.

• The CRL is not signed by the CA certificate configured in the CA profile.

• The CRL version is wrong.

• The CRL expired or is not yet valid.

If the IPsec application needs to use the CRL of a specific ca-profile to check revocation status of an end entity certificate and CRL is non-existent because of the above reasons, then the system treats it as unable to get an answer from CRL and fall back to the secondary status-verify method or default-result configured under the ipsec-gw/ipsec-tunnel.

If the system needs to check the revocation of a CA certificate in certificate chain, and if the CRL is non-existent because of the above reasons, then the system skips checking the revocation status of the CA certificate. For example, the CA1 is issued by CA2, if CA2’s revocation-check is crl-optional and CA2’s CRL is non-existent, then the system does not check CA1 certificate’s revocation status and consider it as good.

The user must disable the ca-profile to change the revocation-check configuration.

For details about OCSP, see OCSP.

The system can optionally generate a warning message before a certificate or a CRL expires. The amount of time before expiration is configurable via two system-wide CLI commands (certificate-expiration-warning and crl-expiration-warning). The warning messages can also be optionally repeated at a configured interval. For details of the warning messages, refer to the corresponding command descriptions.

If a configured EE certificate expires, the system does not bring down an established ipsec-tunnel/ipsec-gw down, however future certificate authentication fails.

If a CA certificate expires, the system brings the ca-profile operationally down. This does not affect established tunnels, however future certificate authentication that uses the ca-profile fails.

Configured certificates, CRLs, and keys are cached in memory before they are used by the system.

• Every certificate/CRL/Key has one cache copy system-wide.

• For a CA certificate and CRL, the cache is created when there is a ca-profile and when it has been administratively enabled, and removed.

• For an ipsec-tunnel or ipsec-gw using legacy cert and key configurations, the cache is created only when the first tunnel using it is in an administratively enabled state, and it is cleared when the last tunnel that used it is administratively disabled.

• For an ipsec-tunnel or ipsec-gw using cert-profile, the cache is created when the first cert-profile using it is in an administratively disabled state, and removed when the last cert-profile that used it is in an administratively disabled state.

• If a certificate or key is configured with both a cert-profile and legacy cert or key command, then the cache is created when the first object (a ipsec-gw, ipsec-tunnel or cert-profile) using it is in an administratively enabled state and removed the last object using it is in an administratively disabled state.

To update a certificate or key without a administratively disabling the ca-profile or ipsec-tunnel/ipsec-gw, use the following command to manually reload the certificate and key cache:

• MD-CLI

  admin system security pki reload

  See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide for more information.

• classic CLI

  admin certificate reload

  See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide for more information.

The SR OS provides an automatic mechanism to update a CRL file. The system tries to download the CRL from a list of configured HTTP URLs and replace existing CRL file when a qualified CRL is successfully downloaded. A qualified CRL is a valid CRL signed by the CA and is more recent than the existing CRL. To determine if a downloaded CRL is more recent than an existing CRL, the system compares the This-Update field of the CRL first. If they are the same, the system compares the CRL number extension if present.

The configured HTTP URL must point to a DER-encoded CRL file.

This features supports two types of downloading schedules:

• periodic

  The system downloads a CRL periodically at the interval configured via the periodic-update-interval command. For example, if the periodic-update-interval is 1 day, then the system downloads CRL every 1 day. The minimal periodic-update-interval is 1 hour.

• next-update-based

  The system downloads a CRL at the time = Next_Update_time_of_current_CRL minus pre-update-time. For example, if the Next-Update of current CRL is 2015-06-30 06:00 and pre-update-time is 1 hour, then the system starts the download at 2015-06-30, 05:00.

The system allows up to eight URLs to be configured for a ca-profile. When downloading begins, URLs are tried in order, and the first successfully downloaded qualified CRL is used to update existing CRL. If the downloading fails or the downloaded CRL is not qualified, the system moves to the next URL in the list. If all URLs in the list fail to return a qualified URL, then:

• In case of next-update-based schedule, the system waits for a configured retry-interval before retrying from the first URL in the list again.

• In case of periodic schedule, the system waits until the next scheduled time.

Upon executing a no shutdown of a ca-profile, if the auto-crl-update is enabled, then in case configures CRL file does not exist or is expired or invalid, then the system starts downloading right away.

The system also provides an admin command (admin certificate crl-update ca <ca-profile-name>) for users to manually trigger downloading. However, it requires a shutdown of the auto-crl-update command (no auto-crl-update).

HTTP transport can be over either IPv4 or IPv6.

This feature support Base/Management/VPRN routing instance. VPLS management is not supported. In the case of VPRN, the HTTP server port can only be 80 or 8080.

CMPv2, RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol(CMP) is a protocol between a Certificate Authority (CA) and an end entity. It provides multiple certificate management functions like certificate enrollment, certificate update, and so on.

The SR OS supports following CMPv2 operations:

• initial registration

  This is the process the SR OS uses to enroll a certificate with a specific CA for the first time.

  • Public/private key pair must be pre-provisioned before enrollment by means of local generation or other methods.

  • Users can optionally include a certificate or certificate chain in the extraCerts field of the initial registration request.

• key pair update

  This is a process for SR OS to update an existing certificate because of reasons like refreshes key/cert before it expires or any other reason.

• certificate update

  This is a process where an initialized SR OS system obtains additional certificates.

• polling

  In some cases, the CA may not return the certificate immediately for reasons such as request processing need manual intervention. In such cases, the SR OS supports polling requests and responds as described in Section 5.3.22, Polling Request and Response, in RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP).

The following lists some implementation details:

• HTTP is the only supported transport protocol for CMPv2. HTTP 1.1 and 1.0 are supported and configurable.

• All CMPv2 messages sent by SR OS consist of only one PKI Message. The size of the sequence for PKI Messages are 1 in all cases.

• Both the password-based MAC and the public key-based signature CMPv2 message protection are supported.

• SR OS only allows one outstanding ir/cr/kur request for each CMPv2 server. The means that no new requests are allowed if a pending request is present.

There are two storage formats for imported certificates, keys, and CRLs:

• legacy, where only the imported key is encrypted

• enhanced secure, where:

  • The encryption algorithm is stronger than the legacy format.

  • Imported certificates and keys are both encrypted.

  • The internal key for encryption is chassis specific. In the case of VSR, the key is VM UUID specific.

  • A compressed format is used for imported CRL files to save space.

The legacy format is used in SR OS releases before Release 16.0.R6. The enhanced secure format is used for all imported files from Release 16.0.R6 onward. By default, the system loads an imported file in both legacy and enhanced secure formats.

Use the following command to configure the system to only load imported files in the enhanced secure format.

configure system security pki imported-format secure

Use the following command to convert imported files between the legacy format and the enhanced secure format.

admin certificate convert-file

The Enrollment over Secure Transport (EST) protocol as specified in RFC 7030, Enrollment over Secure Transport, is used to enroll a certificate from a Certificate Authority (CA). SR OS supports the following EST client-side operations:

• download a CA certificate (/cacert)

• enroll a new certificate (/simpleenroll)

• renew an existing certificate (/simplereenroll)

Use the commands in the following context to perform the EST client-side operations. Each operation requires an EST profile which contains the EST configuration:

• MD-CLI

  admin system security pki est

• classic CLI

  admin certificate est

The following option is supported for SR OS client to authenticate the EST server:

Use the following command to configure Explicit TA which is referenced in the EST profile.

configure system security tls client-tls-profile trust-anchor-profile 

No authentication is performed if this option is not configured.

The following options are supported for the EST server authentication to the SR OS client:

• Use the commands in the following contexts to achieve the client certificate authentication by configuring the certificate profile name for the client TLS profile referenced in the EST profile.

  configure system security tls cert-profile
  configure system security tls client-tls-profile

• Use the following command to configure HTTP authentication.

  • MD-CLI

    configure system security pki est-profile http-authentication

  • classic CLI

    configure system security pki est-profile http-auth 

• Use the following command to configure the trust anchor profile name referenced in the EST profile.

  configure system security tls client-tls-profile trust-anchor-profile

• No authentication is performed if the preceding options are not configured.

Online Certificate Status Protocol (OCSP) (RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) is used by SR OS applications to determine the (revocation) state of an identified certificate. Unlike CRL, which relies on checking against an off-line file, OCSP provides timely, on-line information about the revocation status of a certificate.

IPsec is the only supported application to use OCSP. With introduction of OCSP, the system supports both CRL and OCSP as the certificate revocation status checking method. For an ipsec-tunnel or ipsec-gw, the user could configure a primary method, a secondary method and a default result to achieve a hierarchical fallback mechanism. If the primary method fails to return a result, the system falls back to the secondary method. If the secondary method fails, the fall back proceeds to a default result.

The following lists implementation details:

• Only an OCSP client function is supported.

• HTTP is the only supported transport protocol.

• OCSP server access via management routing instance is not supported.

• SR OS does not sign an OCSP Request.

• The OCSP response must be signed. The system verifies the response by using the signer’s certificate included in the response. If there is no such certificate, the CA certificate in the ca-profile is used.

• If a nextUpdate exists in the OCSP response, the system checks the current time <= nextUpdate. If yes, then the response is valid, otherwise the response is considered unreliable. The system moves to next revocation checking method.

• The revocation status result from a valid OCSP response is cached in the system.

• OCSP can only be used to verify the revocation status of the end-entity certificate. CRL is still needed for CA certificate’s status verification.

SR OS supports automatic updating of an imported end-entity certificate by using an online enrollment protocol with CA. The following enrollment protocols are supported:

• CMPv2 (RFC 4210)

• EST (RFC 7030)

For each certificate that needs an automatic update, a certificate-auto-update command entry must be configured as well as the corresponding certificate-update-profile command. The certificate-update-profile command specifies the update behavior such as the enrollment protocol to use, the schedule type, and so on.

The following events may trigger an update:

• When the current time passes a user-specified deadline, the deadline can be configured as one of the schedule types in certificate-update-profile:

  • before-expiry configures the time before the certificate expiration time

  • after-issue configures the time after certificate issue time

• When a certificate-auto-update entry is configured, and it is already time to do an update.

  If the certificate already expired:

  • for CMPv2, the update fails because CMPv2 does not allow using an expired certificate

  • for EST, if a different certificate is used for TLS authentication, the update is completed

• Manually, by using the following command.

  • MD-CLI

    admin system security pki update-certificate
    

  • classic CLI

    admin certificate update-cert