Digital Certificates with PKI Overview

 

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users to both securely exchange data over networks such as the Internet and verify the identity of the other party.

Understanding Certificates and PKI

A digital certificate is an electronic means for verifying your identity through a trusted third party, known as a certificate authority (CA). Alternatively, you can use a self-signed certificate to attest to your identity.

The CA server you use can be owned and operated by an independent CA or by your own organization, in which case you become your own CA. If you use an independent CA, you must contact them for the addresses of their CA and certificate revocation list (CRL) servers (for obtaining certificates and CRLs) and for the information they require when submitting personal certificate requests. When you are your own CA, you determine this information yourself.

The Public Key Infrastructure (PKI) provides an infrastructure for digital certificate management.

This topic includes the following sections:

Certificate Signatures and Verification

The CA that issues a certificate uses a hash algorithm to generate a digest, and then “signs” the certificate by encrypting the digest with its private key. The result is a digital signature. The CA then makes the digitally signed certificate available for download to the person who requested it. Figure 1 illustrates this process.

The recipient of the certificate generates another digest by applying the same hash algorithm to the certificate file, then uses the CA's public key to decrypt the digital signature. By comparing the decrypted digest with the digest just generated, the recipient can confirm the integrity of the CA's signature and, by extension, the integrity of the accompanying certificate. Figure 1 illustrates this process.

Note

A certificate is considered valid if the digital signature can be verified and the serial number of the certificate is not listed in a certificate revocation list.

Figure 1: Digital Signature Verification
Digital Signature Verification

When Digital Signature Algorithm (DSA) signatures are used, the SHA-1 hash algorithm is used to generate the digest. When Rivest-Shamir-Adleman (RSA) signatures are used, SHA-1 is the default hash algorithm used to generate the digest; you can specify the SHA-256 hash algorithm with the digest option of the request security pki generate-certificate-request or request security pki local-certificate generate-self-signed commands. When Elliptic Curve Digital Signature Algorithm (ECDSA) signatures are used, the SHA-256 hash algorithm is used for ECDSA-256 signatures and the SHA-384 hash algorithm is used for ECDSA-384 signatures.

Starting in Junos OS Release 18.1R3, the default encryption algorithm that is used for validating automatically and manually generated self-signed PKI certificates is Secure Hash Algorithm 256 (SHA-256). Prior to Junos OS Release 18.1R3, SHA-1 is used as default encryption algorithm.

Public Key Infrastructure

To verify the trustworthiness of a certificate, you must be able to track a path of certified certificate authorities (CAs) from the one issuing your local certificate to the root authority of a CA domain. Public key infrastructure (PKI) refers to the hierarchical structure of trust required for the successful implementation of public key cryptography.

Figure 2 shows the structure of a single-domain certificate authority with multiple hierarchy levels.

Figure 2: PKI Hierarchy of Trust—CA Domain
PKI Hierarchy of Trust—CA Domain

If certificates are used solely within an organization, that organization can have its own CA domain within which a company CA issues and validates certificates for its employees. If that organization later wants its employees to exchange their certificates with certificates from another CA domain (for example, with employees at another organization that has its own CA domain), the two CAs can develop cross-certification by agreeing to trust the authority of each other. In this case, the PKI structure does not extend vertically but does extend horizontally. See Figure 3.

Figure 3: Cross-Certification
Cross-Certification

PKI Management and Implementation

The minimum PKI elements required for certificate-based authentication in Junos OS are:

  • CA certificates and authority configuration.

  • Local certificates including the device’s identity (example: IKE ID type and value) and private and public keys

  • Certificate validation through a CRL.

Junos OS supports three different types of PKI objects:

  • Private/public key pair

  • Certificates

    • Local certificate—The local certificate contains the public key and identity information for the Juniper Networks device. The Juniper Networks device owns the associated private key. This certificate is generated based on a certificate request from the Juniper Networks device.

    • Pending certificate — A pending certificate contains a key pair and identity information that is generated into a PKCS10 certificate request and manually sent to a certificate authority (CA). While the Juniper Networks device waits for the certificate from the CA, the existing object (key pair and the certificate request) is tagged as a certificate request or pending certificate.

Internet Key Exchange

The procedure for digitally signing messages sent between two participants in an Internet Key Exchange (IKE) session is similar to digital certificate verification, with the following differences:

  • Instead of making a digest from the CA certificate, the sender makes it from the data in the IP packet payload.

  • Instead of using the CA's public-private key pair, the participants use the sender's public-private key pair.

Trusted CA Group

A Certificate Authority (CA) is a trusted third party responsible for issuing and revoking certificates. You can group multiple CAs (CA profiles) in one trusted CA group for a given topology. These certificates are used to establish connection between two endpoints. To establish IKE or IPsec, both the endpoints must trust the same CA. If either of the endpoints are unable to validate the certificate using their respective trusted CA (ca-profile) or trusted CA group, the connection is not established.

For example, there are two endpoints, endpoint A and endpoint B are trying to establish a secure connection. When endpoint B presents it’s certificate to endpoint A, the endpoint A will check if the certificate is valid. The CA of the endpoint A verifies the signed certificate that the endpoint B is using to get authorized. When trusted-ca or trusted-ca-group is configured, the device will only use the CA profiles added in this trusted-ca-group or the CA profile configured under trusted-ca to validate the certificate coming from endpoint B. If the certificate is verified as valid, the connection is allowed, else the connection is rejected.

Benefits:

  • For any incoming connection request, only the certificate issued by that particular trusted CA of that endpoint gets validated. If not, the authorization will reject establishing the connection.

Cryptographic Key Handling Overview

With cryptographic key handling, persistent keys are stored in the memory of the device without any attempt to alter them. While the internal memory device is not directly accessible to a potential adversary, those who require a second layer of defense can enable special handling for cryptographic keys. When enabled, the cryptographic key handling encrypts keys when not immediately in use, performs error detection when copying a key from one memory location to another, and overwrites the memory location of a key with a random bit pattern when the key is no longer in use. Keys are also protected when they are stored in the flash memory of the device. Enabling cryptographic key handling feature does not cause any externally observable change in the behavior of the device, and the device continues to interoperate with the other devices.

Note

A cryptographic administrator can enable and disable the cryptographic self-test functions; however, the security administrator can modify the behavior of the cryptographic self-test functions such configuring periodic self-tests or selecting a subset of cryptographic self-tests.

The following persistent keys are currently under the management of IKE and PKI:

  • IKE preshared keys (IKE PSKs)

  • PKI private keys

  • Manual VPN keys

Understanding Public Key Cryptography

The public-private key pairs used in public key cryptography play an important role in the use of digital certificates. A public-private key pair encrypts and decrypts data. Data encrypted with a public key, which the owner makes available to the public, can be decrypted with the corresponding private key only, which the owner keeps secret and protected. For example, if Alice wants to send Bob an encrypted message, Alice can encrypt it with Bob's public key and send it to him. Bob then decrypts the message with his private key.

The reverse process is also useful: encrypting data with a private key and decrypting it with the corresponding public key. This process is known as creating a digital signature. For example, if Alice wants to present her identity as the sender of a message, she can encrypt the message with her private key and send the message to Bob. Bob then decrypts the message with Alice's public key, thus verifying that Alice is indeed the sender.

When you generate a public-private key pair, the device automatically saves the key pair in a file in the certificate store, where it is subsequently used in certificate request commands. The generated key pair is saved as certificate-id.

Note

The default RSA and DSA key size is 1024 bits. Simple Certificate Enrollment Protocol (SCEP) supports RSA certificates only. CMPv2 supports RSA, DSA, and ECDSA certificate types.

Note

If the device renews a great number of certificates at once, thus using up keys rapidly, it might run out of pregenerated keys and have to generate them promptly for each new request. In this case, the generation of keys might affect the performance of the device, especially in a high-availability environment where the performance of the device might slow down for a number of minutes.

Configuring a Trusted CA Group

This section describes the procedure to create a trusted CA group for a list of CA profiles and delete a trusted CA group.

Creating a Trusted CA Group for a List of CA Profiles

You can configure and assign a trusted CA group to authorize an entity. When a peer tries to establish a connection with a client, only the certificate issued by that particular trusted CA of that entity gets validated. The device validates if the issuer of the certificate and the one presenting the certificate belongs to the same client network. If the issuer and the presenter belong to the same client network then the connection is established. If not, the connection will not be established.

Before you begin, you must have a list of all the CA profiles you want to add to the trusted group.

In this example, we are creating three CA profiles named orgA-ca-profile, orgB-ca-profile, and orgC-ca-profile and associating the following CA identifiers ca-profile1, ca-profile2, and ca-profile3 for the respective profiles. You can group all the three CA profiles to belong to a trusted CA group orgABC-trusted-ca-group.

Note

You can configure a maximum of 20 CA profiles for a trusted CA group.

  1. Create CA profiles and associate CA identifiers to the profile.
  2. Group the CA profiles under a trusted CA group.
  3. Commit the configuration when you are done configuring the CA profiles and the trusted CA groups.

To view the CA profiles and the trusted CA groups configured on your device, run show security pki command.

The show security pki command displays all the CA profiles that are grouped under the orgABC_trusted-ca-group.

Deleting a CA Profile from a Trusted CA Group

You can delete a specific CA profile in a trusted CA group or you can delete the trusted CA group itself.

For example, if you want to delete a CA profile named orgC-ca-profile from a trusted CA group orgABC-trusted-ca-group, configured on your device as shown in Creating a Trusted CA Group for a List of CA Profiles topic perform the following steps:

  1. Delete a CA profile from the trusted CA group.
  2. If you are done deleting the CA profile from the trusted CA group, commit the configuration.

To view the orgC-ca-profile being deleted from the orgABC-trusted-ca-group , run the show security pki command.

The output does not display the orgC-ca-profile profile as it is deleted from the trusted CA group.

Deleting a Trusted CA Group

An entity can support many trusted CA groups and you can delete any trusted CA group for an entity.

For example, if you want to delete a trusted CA group named orgABC-trusted-ca-group, configured on your device as shown in Creating a Trusted CA Group for a List of CA Profiles topic perform the following steps:

  1. Delete a trusted CA group.
  2. If you are done deleting the CA profile from the trusted CA group, commit the configuration.

To view the orgABC-trusted-ca-group being deleted from the entity , run the show security pki command.

The output does not display the orgABC-trusted-ca-group as it is deleted from the entity.

Digital Certificates Configuration Overview

You can obtain CA and local certificates manually, or online using Simple Certificate Enrollment Protocol (SCEP) or CMPv2. Certificates are verifiable and renewable, and you can delete them when they are no longer needed.

Manual certificate processing includes generation of a PKCS10 request, submission to the CA, retrieval of the signed certificate, and manually loading the certificate into the Juniper Networks device. Based on your deployment environment, you can use either SCEP or CMPv2 for online certificate enrollment.

To use a digital certificate to authenticate your identity when establishing a secure VPN connection, you must first do the following:

  • Obtain a CA certificate from which you intend to obtain a local certificate, and then load the CA certificate onto the device. The CA certificate can contain a CRL to identify invalid certificates.

  • Obtain a local certificate from the CA whose CA certificate you have previously loaded, and then load the local certificate in the device. The local certificate establishes the identity of the Juniper Networks device with each tunnel connection.

This topic includes the following sections:

Enrolling Digital Certificates Online: Configuration Overview

You can use either Certificate Management Protocol version 2 (CMPv2) or Simple Certificate Enrollment Protocol (SCEP) to enroll digital certificates. To enroll a certificate online:

  1. Generate a key pair on 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. For SCEP only, enroll the CA certificate. See Enrolling a CA Certificate Online Using SCEP.

  4. Enroll the local certificate from the CA whose CA certificate you have previously loaded. See Example: Enrolling a Local Certificate Online Using SCEP.

  5. Configure automatic reenrollment. See Example: Using SCEP to Automatically Renew a Local Certificate.

Manually Generating Digital Certificates: Configuration Overview

To obtain digital certificates manually:

  1. Generate a key pair on 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. Generate the CSR for the local certificate and send it to the CA server. 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: Using SCEP to Automatically Renew a Local Certificate.

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

  7. If necessary, configure the CA profile with CRL locations. See Example: Configuring a Certificate Authority Profile with CRL Locations

Example: Generating a Public-Private Key Pair

This example shows how to generate a public-private key pair.

Requirements

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

Overview

In this example, you generate a public-private key pair named ca-ipsec.

Configuration

Step-by-Step Procedure

To generate a public-private key pair:

  • Create a certificate key pair.

Verification

After the public-private key pair is generated, the Juniper Networks device displays the following:

Understanding Digital Certificate Validation

During IKE negotiation, the PKI daemon on an SRX Series device validates X509 certificates received from VPN peers. The certificate validation performed is specified in RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Basic certificate and certificate chain validations include signature and date validation as well as revocation checks. This topic describes additional digital certificate validations performed by the PKI daemon.

Policy Validation

X509 certificates can include optional policy validation fields. If a policy validation field is present, policy validation is performed for the entire certificate chain including the end entity (EE) certificate and intermediate certificate authority (CA) certificates. Policy validation is not applicable to the root certificate. Policy validation ensures that the EE and intermediate CA certificates have a common policy. If no common policy exists for the certificate chain being validated, certificate validation fails.

Prior to policy validation, a certificate chain containing the self-signed root certificate, intermediate CA certificates, and EE certificate must be built. The policy validation starts with the intermediate CA certificate issued by the self-signed root certificate and continues through the EE certificate.

The following optional certificate fields are used for policy validation:

  • policy-oids

  • requireExplicitPolicy

  • skipCerts

These fields are described in the following sections.

Policy OIDs Configured on SRX Series Devices

In some situations, it might be desirable to only accept certificates with known policy object identifiers (OIDs) from peers. This optional configuration allows certificate validation to succeed only if the certificate chain received from the peer contains at least one policy OID that is configured on the SRX Series device.

On the SRX Series device, policy OIDs are configured in an IKE policy with the policy-oids configuration statement at the [edit security ike policy policy-name certificate] hierarchy level. You can configure up to five policy OIDs. For a peer’s certificate to be validated successfully, the peer’s certificate chain must contain at least one of the policy OIDs configured on the SRX Series device. Note that the policy-oids field in a certificate is optional. If you configure policy OIDs on the SRX Series device but the peer’s certificate chain does not contain any policy OIDs, certificate validation fails.

No Policy OIDs Configured on SRX Series Devices

If no policy OID is configured on the SRX Series device, policy validation starts whenever the requireExplicitPolicy field is encountered in the certificate chain. A certificate can contain one or more certificate policy OIDs. For policy validation to succeed, there must be a common policy OID in the certificate chain.

Figure 4 shows a certificate chain that consists of certificates for a root CA, three intermediate CAs, and an EE. The CA certificate for Int-CA-2 contains the requireExplicitPolicy field; therefore, policy validation starts with Int-CA-2 and continues through EE-1. The certificate for Int-CA-2 contains policy OIDs P1, P2, and P3. The certificate for Int-CA-3 contains policy OIDs P2, P3, and P4. The certificate for EE-1 contains policy OIDs P2 and P5. Because the policy OID P2 is common to the certificates being validated, policy validation succeeds.

Figure 4: Policy Validation with requireExplicitPolicy Field
 Policy Validation with requireExplicitPolicy Field

The optional skipCerts field in an intermediate CA certificate indicates the number of certificates, including the current CA certificate, that are to be excluded from policy validation. If skipCerts is 0, policy validation starts from the current certificate. If skipCerts is 1, the current certificate is excluded from policy validation. The value of the skipCerts field is checked in every intermediate CA certificate. If a skipCerts value is encountered that is lower than the current number of certificates being excluded, the lower skipCerts value is used.

Figure 5 shows a certificate chain consisting of a root CA, four intermediate CAs, and an EE. The skipCerts value in Int-CA-1 is 12, which skips 12 certificates including the certificate for Int-CA-1. However, the skipCerts value is checked in every intermediate CA certificate in the chain. The skipCerts value in Int-CA-2 is 2, which is lower than 12, so now 2 certificates are skipped. The skipCerts value in Int-CA-4 is 5, which is greater than 2, so the Int-CA-4 skipCerts value is ignored.

Figure 5: Policy Validation with skipCerts Field
 Policy
Validation with skipCerts Field

When policy OIDs are configured on the SRX Series device, the certificate fields requireExplicitPolicy and skipCerts are ignored.

Path Length Validation

Certificate validation can involve a certificate chain that includes a root CA, one or more optional intermediate CAs, and an EE certificate. The number of intermediate CAs can grow depending upon the deployment scenario. Path length validation provides a mechanism to limit the number of intermediate certificates involved in certificate validation. path-length is an optional field in an X509 certificate. The value of path-length indicates the number of non-self-signed intermediate CA certificates allowed for certificate validation. The last certificate, which is generally the EE certificate, is not included in the path limit. If the root certificate contains a path-length value of 0, no intermediate CA certificates are allowed. If the path-length value is 1, there can be 0 or 1 intermediate CA certificates.

path-length can be present in multiple CA certificates in the certificate chain. The path length validation always begins with the self-signed root certificate. The path limit is decremented by 1 at each intermediate certificate in the chain. If an intermediate certificate contains a path-length value less than the current path limit, the new limit is enforced. On the other hand, if the path-length value is larger than the current path limit, it is ignored.

Figure 6 shows a certificate chain that consists of a root CA, four intermediate CAs, and an EE. The path-length value in Root-CA is 10, therefore the initial path limit of non-self-signed intermediate CA certificates allowed for certificate validation is 10. At Int-CA-1, the path limit is 10-1 or 9. The path-length value in Int-CA-1 is 4, which is less than the path limit of 9, so the new path limit becomes 4. At Int-CA-2, the path limit is 4-1 or 3. The path-length value in Int-CA-2 is 5, which is larger than the path limit of 3, so it is ignored. At Int-CA-3, the path limit is 3-1 or 2. The path-length value in Int-CA-3 is 20, which is larger than the path limit of 2, so it is also ignored.

Figure 6: Path Length Validation
 Path Length Validation

Key Usage

The key usage field in an EE or CA certificate defines the purpose of the key contained in the certificate.

EE Certificates

For EE certificates, if the key usage field is present but the certificate does not contain digitalSignature or nonrepudiation flags, the certificate is rejected. If the key usage field is not present, then key usage is not checked.

CA Certificates

The key can be used for certificate or CRL signature validation. Because the PKI daemon is responsible for both X509 certificate validation and CRL downloads, key usage must be checked before validating the certificate or CRL.

Certificate Signature Validation

The keyCertSign flag indicates that a CA certificate can be used for certificate signature validation. If this flag is not set, certificate validation is aborted.

CRL Signature Validation

In Phase 1 negotiations, participants check the certificate revocation list (CRL) to see if certificates received during an IKE exchange are still valid. The CRL is periodically downloaded for CA profiles configured with CRL as the certificate revocation check. Downloaded CRL files must be verified before they are downloaded into the device. One of the verification steps is to validate the CRL signature using a CA certificate. The downloaded CRL is signed with the CA certificate’s private key and it must be verified with the CA certificate’s public key stored in the device. The key usage field in the CA certificate must contain the CRLSign flag to verify the downloaded CRL. If this flag is not present, the CRL is discarded.

Issuer and Subject Distinguished Name Validation

Signature validation is performed for certificates received from a peer as well as for the CRL file downloaded from a CA server. Signature validation involves looking up the CA certificate in a CA database based on the issuer’s distinguished name (DN) in the certificate or the CRL being verified.

Figure 7 shows the lookup for CA certificates based on the issuer DN. In the EE certificate, the issuer DN is CA-1, which is the subject DN of the intermediate CA certificate in the chain. In the intermediate CA certificate, the issuer DN is CA-Root, which is the subject DN of the self-signed Root-CA certificate in the chain. In the CRL, the issuer DN is CA-Root, which is the subject DN of the self-signed Root-CA certificate.

Figure 7: Issuer and Subject DN Validation
 Issuer and Subject
DN Validation

The lookup for the issuer or subject DN must follow these rules for attribute values:

  • Attribute values encoded in different ASN.1 types (for example, PrintableString and BMPString) are assumed to represent different strings.

  • Attribute values encoded in PrintableString types are not case-sensitive. These attribute values are compared after removing leading and trailing white spaces and converting internal substrings of one or more consecutive white spaces to a single space.

  • Attribute values encoded in types other than PrintableString are case-sensitive.

Example: Validating Digital Certificate by Configuring Policy OIDs on an SRX Series Device

In some situations, it might be desirable to only accept certificates with known policy object identifiers (OIDs) from peers. This optional configuration allows certificate validation to succeed only if the certificate chain received from the peer contains at least one policy OID that is configured on the SRX Series device. This example shows how to configure policy OIDs in the IKE policy on an SRX Series device.

Note

You must ensure that at least one of the policy OIDs configured on the SRX Series device is included in a peer’s certificate or certificate chain. Note that the policy-oids field in a peer’s certificate is optional. If you configure policy OIDs in an IKE policy and the peer’s certificate chain does not contain any policy OIDs, certificate validation for the peer fails.

Requirements

Before you begin:

  • Ensure that you are using Junos OS Release 12.3X48-D10 or later for SRX Series devices.

  • Configure an IPsec VPN tunnel. See IPsec VPN with Autokey IKE Configuration Overview. The complete IKE phase 1 and phase 2 VPN tunnel configuration is not shown in this example.

Overview

This example shows an IKE policy configuration where policy OIDs 2.16.840.1.101.3.1.48.2 and 5.16.40.1.101.3.1.55.2 are specified. The IKE policy ike_cert_pol references the IKE proposal ike_cert_prop, which is not shown. The local certificate on the SRX Series device is lc-igloo-root.

Configuration

CLI Quick Configuration

To quickly configure this example, 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 policy OIDs for certificate validation:

  • Configure the IKE policy:

Results

From configuration mode, confirm your configuration by entering the show security ike policy ike_cert_pol command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

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

Verification

Confirm that the configuration is working properly.

Verifying the CA Certificate

Purpose

Display the CA certificate configured on the device.

Action

From operational mode, enter the show security pki ca-certificate ca-profile ca-tmp command.

user@host> show security pki ca-certificate ca-profile ca-tmp detail

Verifying Policy OID Validation

Purpose

If the peer’s certificate is successfully validated, IKE and IPsec security associations are established. If the validation of the peer’s certificate fails, no IKE security association is established.

Action

From operational mode, enter the show security ike security-associations and show security ipsec security-associations commands.

user@host> show security ike security-associations
user@host> show security ipsec security-associations

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs. If no SAs are listed, there was a problem with Phase 1 establishment. In this case, check for the PKID_CERT_POLICY_CHECK_FAIL message in the system logs. This message indicates that the peer’s certificate chain does not contain a policy OID that is configured on the SRX Series device. Check the policy-oids values in the peer’s certificate chain with the values configured on the SRX Series device.

It might also be that the peer’s certificate chain does not contain any policy-oids fields, which are optional fields. If this is the case, certificate validation fails if there are any policy OIDs configured on the SRX Series device.

Release History Table
Release
Description
Starting in Junos OS Release 18.1R3, the default encryption algorithm that is used for validating automatically and manually generated self-signed PKI certificates is Secure Hash Algorithm 256 (SHA-256). Prior to Junos OS Release 18.1R3, SHA-1 is used as default encryption algorithm.