Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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.

    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.

    Modified: 2018-03-14