Public Key Infrastructure (PKI)
This topic describes the overview of public key infrastructure and includes the following sections:
Introduction to PKI
Public key infrastructure (PKI) provides a way of verifying the identity of a remote site by using a digital certificate. PKI uses a certificate authority (CA) to validate your information and to sign it with a digital signature such that neither your information nor the signature can be modified. Once signed, the information becomes a digital certificate. Devices that receive a digital certificate can verify the information in the certificate by validating the signature using public key cryptography.
The Public Key Infrastructure (PKI) provides an infrastructure for digital certificate management and consists of:
Registration Authority (RA) that verifies the identities of entities, authorizes their certificate requests, and generates unique asymmetric key pairs (unless the users’ certificate requests already contain public keys)
Certificate Authority (CA) that issues corresponding digital certificates for the requesting entities.
A certificate revocation list (CRL) identifying the certificates that are no longer valid. Each entity possessing the authentic public key of a CA can verify the certificates issued by that CA.
Digital Certificate
A digital certificate is an electronic file that verifies the identity of the certificate’s holder to protect data exchanged online. Digital certificates provide a way of authenticating users through a trusted third party called a certificate authority (CA). The CA validates the identity of a certificate holder and “signs” the certificate to attest that it has not been forged or altered. Alternatively, you can use a self-signed certificate to attest to your identity.
A key pair is a critical element of a digital certificate implementation. The public key is included in the local digital certificate and the private key is used to decrypt data received from peers.
Certificates have a finite lifetime and are defined by a start time and an end time. The certificate becomes invalid when the life time expires. When the certificate expires, a certificate renewal or a new certificate request is required.
Certificate Authority
A CA is a trusted third-party organization that creates, enrolls, validates, and revokes digital certificates. The CA guarantees a user’s identity and issues public and private keys for message encryption and decryption (coding and decoding). A CA also generates certificate revocation lists (CRLs) which are lists of revoked certificates.
Private/Public Key Pair
When setting up a PKI, you must include Public and private keys that are generated in pairs and linked mathematically.
When request for the certificate, you must include the public key in the certificate enrollment request. The public key will be included in the granted certificate and the private key is kept on the requesting device. A message encrypted with the public key can be decrypted by using the corresponding private key. The private-public key pair is also used for creating digital signatures.
Certificate Enrollment Options
You can request a CA digital certificate either online or manually:
Manual certificate enrollment—This process includes generation of a PKCS10 request, submission to the certificate authority (CA), retrieval of the signed certificate, and manually loading of the certificate into the Junos OS device as the local certificate.
Online certificate enrollment—You can use either Certificate Management Protocol version 2 (CMPv2) or Simple Certificate Enrollment Protocol (SCEP) for online certificate enrollment.
Certificate Revocation Options
Certificate revocation list (or CRL)—Certificate authority (CA) periodically publishes a list of revoked certificate using a certificate revocation list (CRL). The CRL contains the list of digital certificates with serial numbers that have been canceled before their expiration date.
Online Certificate Status Protocol (OCSP)—OCSP is used to check the revocation status of X509 certificates. The OCSP provides revocation status on certificates in real time and is useful in time-sensitive situations such as bank transactions and stock trades
Certificate Request Types
Public Key Infrastructure (PKI) allows users to authenticate each other using digital certificates issued by CA. PKI Uses X.509, Public Key Cryptography Standards (PKCS) to define the standard formats for certificates and their use. In PKI, an applicant uses a certificate signing request (CSR) to apply for a digital certificate to a certificate authority (CA). The request can be in one of the standard:
Public-Key Cryptography Standard # (PKCS#) (PKCS7, PKCS10, PKCS11, PKCS12)
x509-signaturere.
Certificate Signatures and Verification
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 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.
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.
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 hash 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 hash algorithm.
Certificate Validation
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.
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.
