Public key infrastructure

The SR OS PKI implementation supports the following features:

• Supported public key algorithm: RSA/DSA/ECDSA

• Certificate enrollment includes:

  • Locally generated RSA/DSA/ECDSA key

  • Offline enrollment via PKCS#10

  • Online enrollment via Certificate Management Protocol version 2 (CMPv2)

  • Online 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

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

• CA Certificate

• CRL

• certificate of the system

• key of the system

Before they can be used by SR OS, use the following command to import the preceding objects:

• MD-CLI

  admin system security pki import

• classic CLI

  admin certificate import

The import process converts the format of input file to DER, encrypts it, and saves it in the cf3:/system-pki directory.

The imported file can also be exported as one to use in the specified format by means of the following command:

• MD-CLI

  admin system security pki export

• classic CLI

  admin certificate export

The preceding commands support the following formats:

• Certificates can be imported or exported using the 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 pairs can be imported or exported by using the following formats:

  • PKCS#12 (must along with certificate)

  • PEM

  • DER

• CRL can be imported or exported by using the 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.

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 or 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, 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, the system still keeps the CA profile operationally up, but treats 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 or 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. Use the following commands to configure the amount of time before expiration.

configure system security pki certificate-expiration-warning
configure system security pki crl-expiration-warning

The warning messages can also be optionally repeated at a configured interval. For details of the warning messages, see 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, or 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 is administratively enabled and removed.

• For an IPsec tunnel or IPsec gateway 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 gateway 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, 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 administratively disabled.

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 replaces the 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 the following 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, 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, 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, the following occurs:

• 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.

After administratively enabling a CA profile and with auto-crl-update is enabled, in a case where the CRL file does not exist or is expired or invalid, the system starts downloading immediately.

The system also provides an admin command for users to trigger downloading:

• MD-CLI

  admin system security pki crl-update ca-profile ca-profile-name

• classic CLI

  admin certificate crl-update ca ca-profile-name

However, it requires the user to administratively disable the auto-crl-update command using the following command:

• MD-CLI

  configure system security pki ca-profile auto-crl-update admin-state disable

• classic CLI

  configure system security pki ca-profile no auto-crl-update

HTTP transport can be over either IPv4 or IPv6.

This feature supports a base, management, or VPRN routing instance. VPLS management is not supported. For 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.

SR OS supports following CMPv2 operations:

• initial registration

  This is the process 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 needing manual intervention. In such cases, 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.

• If a CMPv2 PKIConf message does not contain the extraCerts field and the system is configured to use extraCerts to verify the message, the extraCerts field from a previously received response message, such as the initial registration response or the key update response, is used.

The following 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 and later. 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:

• MD-CLI

  admin system security pki convert-file

• classic CLI

  admin certificate convert-file

The Enrollment over Secure Transport (EST) protocol as described 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:

• downloading a CA certificate (/cacert)

• enrolling a new certificate (/simpleenroll)

• renewing an existing certificate (/simplereenroll)

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

• MD-CLI

  admin system security pki est

• classic CLI

  admin certificate est

The following option is supported for the 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 the 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