Understanding Certificates and PKI

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

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.

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

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

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.

    Note: Junos OS supports automatic sending of certificate requests through the Simple Certificate Enrollment Protocol (SCEP).

  • CA certificate — When the certificate is issued by the CA and loaded into the Junos device, the pending certificate is replaced by the newly generated local certificate. All other certificates loaded into the device are considered CA certificates.

For convenience and practicality, PKI must be transparently managed and implemented. Toward this goal, Junos OS supports the following features:

• Generates a public-private key pair.
• Loads multiple local certificates from different CAs.
• Delivers a certificate when establishing an IPsec tunnel.
• Validates a certificate path upward through a single level of CA authorities.
• Supports the Public-Key Cryptography Standards #7 (PKCS #7) cryptographic . As a result, the device can accept X.509 certificates and certificate revocation lists (CRLs) packaged within a PKCS #7 envelope.

  Note: Junos OS supports a PKCS #7 file size of up to 7 KB.

• Retrieves CRLs online retrieval through Lightweight Directory Access Protocol (LDAP) or Hypertext Transfer Protocol (HTTP).

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.