What Is PKI?

PKI System Structure

As shown in the figure below, a PKI system consists of the end entity, certificate authority (CA), registration authority (RA), and certificate/certificate revocation list (CRL) storage database.

PKI system structure

• End entity

  An end entity, or PKI entity, is the end user of PKI products or services. It can be an individual, an organization, a device (for example, a router or firewall), or a process running on a computer.

• Certificate Authority (CA)

  A CA is a trusted entity that issues and manages digital certificates. The CA is an authoritative, trusted, and impartial third-party organization. Generally, a CA is a server, for example, a server running Windows Server 2008.

  The following figure shows a hierarchical CA. The CA on the top of the hierarchy is the root CA and the others are subordinate CAs.

  • The root CA is the first CA (trustpoint) in the PKI system. It issues certificates to subordinate CAs, computers, users, and services. In most certificate-based applications, the root CA can be traced through the certificate chain. The root CA holds a self-signed certificate.

  • A subordinate CA can only obtain a certificate from its upper-level CA. The upper-level CA can be the root CA or another subordinate CA authorized by the root CA to issue certificates. The upper-level CA is responsible issuing and managing certificates of lower-level CAs, and the CAs at the bottom issue certificates to end entities. For example, CA 2 and CA 3 are subordinate CAs, holding the certificates issued by CA 1, and CA 4, CA 5, as well as CA 6 are also subordinate CAs, holding the certificates issued by CA 2.

  When a PKI entity trusts a CA, the trust is derived along the certificate chain. A certificate chain is a set of certificates from the end entity to the root certificate. When a PKI entity in communication receives a certificate to be verified, the PKI entity verifies each issuer along the certificate chain.

  
  
  Hierarchical CA model

  Certificate management is the major function of CAs, including issuing, updating, revoking, querying, and archiving certificates as well as distributing the CRL.

• Registration Authority (RA)

  An RA enrolls and approves digital certificates. It is a proxy for the CA and provides extended applications of certificate issuing and management. The RA processes the certificate enrollment and revocation requests from users, verifies user identities, and decides whether to submit certificate issuing or revocation requests to the CA.

  While an RA is combined with a CA in most cases, it can also be independent of a CA, sharing the CA's workload and enhancing CA system security.

• Certificate/CRL database

  A certificate may need to be revoked for the reasons such as entity name changing, private key leaking, or service interruption. Revoking a certificate is to unbind the public key from the PKI entity identity information. The PKI system uses a CRL to revoke certificates.

  After a certificate is revoked, the CA distributes a CRL to declare that the certificate is invalid and lists the serial numbers of revoked certificates. The CRL provides a method to verify certificate validity.

  The certificate/CRL database stores and manages information about certificates and CRLs and allows information query. The certificate/CRL database can be built using a File Transfer Protocol (FTP) server, Hypertext Transfer Protocol (HTTP) server, or database.

PKI manages the entire lifecycle of local certificates, including certificate application, issuing, storage, download, installation, verification, update, and revocation.

Certificate Application

Certificate application, also known as certificate enrollment, is a process in which a PKI entity introduces itself to a CA, which then issues it a certificate. Generally, a PKI entity generates a pair of public and private keys. The public key and entity's identity information (included in certificate enrollment request) are sent to the CA to generate a local certificate. The private key is stored by the PKI entity to perform digital signature and decrypt the ciphertext sent from the peer.

A PKI entity can use either of the following methods to apply for a local certificate from CA:

• Online

  The PKI entity sends certificate enrollment requests to the CA by using the Simple Certificate Enrollment Protocol (SCEP) or Certificate Management Protocol version 2 (CMPv2).

• Offline (PKCS#10)

  The PKI entity prints the local certificate enrollment request in PKCS#10 format and saves it as a file. Then the PKI entity sends the file to the CA in out-of-band mode (such as web, disk, or email).

In addition, a PKI entity can issue a self-signed or local certificate to itself.

Certificate Issuing

If an RA is available, the RA verifies the PKI entity's identity information when the PKI entity applies for a local certificate from a CA. After successful verification, the RA sends the request to the CA. The CA generates a local certificate based on the public key and identity information of the PKI entity, and then returns the local certificate information to the RA. If no RA is available, the CA verifies the PKI entity.

Certificate Storage

After the CA generates a local certificate, the CA or RA distributes the certificate to the certificate/CRL database. Users can download the certificate or browse the directory of the certificate in the database.

Certificate Download

A PKI entity can download a local certificate, a CA/RA certificate, or a local certificate of another PKI entity from the CA server using the SCEP, CMPv2, HTTP, or out-of-band mode.

Certificate Installation

In order for a downloaded certificate to take effect, it must be installed on the device (specifically imported to the device memory). The certificate can be a local certificate of the PKI entity, a CA/RA certificate, or a local certificate of another PKI entity.

Certificate Verification

Before a PKI entity uses a certificate obtained from a peer, for example, for the purposes of setting up a secure tunnel or connection with the peer, the PKI entity verifies the local certificate and CA of the peer (whether the certificate is valid and issued by the expected CA). If the certificate of a CA is invalid, all certificates issued by this CA are invalid. In normal situations, however, this seldom occurs because a device updates the CA certificate before expiration.

A PKI entity can use a CRL or the Online Certificate Status Protocol (OCSP) to check whether a certificate is valid. In CRL mode, the PKI entity searches for the certificate in the CRL stored in the local memory. If the certificate is included in the CRL, it means the certificate has been revoked. If no CRL is available in the local memory, a CRL needs to be downloaded and installed. In OCSP mode, the PKI entity sends a certificate status query message to the OCSP server, and the OCSP server returns the certificate state, which can be valid (not revoked), expired (revoked), or unknown (OCSP server cannot find the certificate state).

Certificate Update

If a certificate expires or the key is disclosed, a PKI entity must replace the certificate. The PKI entity can apply for a new certificate or use SCEP or CMPv2 to automatically update the certificate.

When a certificate is about to expire, the device applies for a shadow certificate. When the certificate expires, the shadow certificate becomes active.

The shadow certificate application process is the enrollment process for the new certificate.

Certificate Revocation

Certificate revocation unbinds a public key of a user from the user's identity. A user needs to revoke its certificate when its identity, information, or public key changes or the service for the user ceases. In PKI, a CA uses a CRL or OCSP to revoke certificates of PKI entities, while a PKI entity revokes its own certificate in out-of-band mode.

PKI Working Mechanism

On a PKI network, a PKI entity applies for a local certificate from the CA and verifies the certificate validity. The following figure shows the PKI working process.

PKI working process

1. A PKI entity applies for a CA certificate (CA server's certificate) from the CA.

2. When receiving the application request, the CA sends its own certificate to the PKI entity.

3. The PKI entity installs the CA certificate.

   If the PKI entity uses SCEP for local certificate application, it performs hash calculation on the received CA certificate to generate a digital fingerprint, and compares the generated digital fingerprint with that pre-defined for the CA server. If the two fingerprints are the same, the PKI entity accepts the CA certificate; otherwise, it discards the CA certificate.

4. The PKI entity sends a certificate enrollment message (including the public key carried in the configured key pair and PKI entity information) to the CA.

   • If the PKI entity uses SCEP for local certificate application, it encrypts the certificate enrollment message using the CA certificate's public key and digitally signs the message using its own private key. If the CA server requires a challenge password, the enrollment message must contain a challenge password, which must be the same as the CA's challenge password.

   • If the PKI entity uses CMPv2 for local certificate application, it uses an additional identity certificate (local certificate issued by another CA) or message authentication code (MAC) for identity authentication.

     • Additional certificate

       The PKI entity uses the CA certificate's public key to encrypt the certificate enrollment message and the private key of the PKI entity's additional certificate to digitally sign the message.

     • MAC

       The PKI entity uses the CA certificate's public key to encrypt the certificate enrollment message and the message must contain the MAC reference value and secret value (the values must be the same as those of the CA).

5. The CA receives the certificate enrollment message from the PKI entity.

   • If the PKI entity uses SCEP to apply for a local certificate, the CA uses its own private key to decrypt the certificate enrollment message and the PKI entity's public key to decrypt the digital signature, and verifies the digital fingerprint. When the fingerprints are the same, the CA verifies the PKI entity's identity information. When the PKI entity's identity information passes verification, the CA accepts the application and issues a local certificate to the PKI entity. The CA uses the PKI entity's public key to encrypt the certificate and its own private key to digitally sign the certificate, and sends the certificate to the PKI entity. At the same time, the CA also sends the certificate to the certificate/CRL database.

   • If the PKI entity uses CMPv2 to apply for a local certificate:

     • Additional certificate

       The CA uses its own private key to decrypt the certificate enrollment request, uses the public key of the PKI entity's additional certificate to decrypt the digital signature, and verifies the digital fingerprint. When the fingerprints are the same, the CA verifies the PKI entity's identity information. When the PKI entity's identity information passes verification, the CA accepts the application and issues a local certificate to the PKI entity. The CA uses the public key of the PKI entity's additional certificate to encrypt the certificate and uses its own private key to digitally sign the certificate, and sends the certificate to the PKI entity. At the same time, the CA also sends the certificate to the certificate/CRL database.

     • MAC

       The CA uses its own private key to decrypt the certificate enrollment message and verifies the MAC reference value and secret value. When the reference value and secret value are the same as those of the CA, the CA verifies the PKI entity's identity information. When the PKI entity's identity information passes verification, the CA accepts the application and issues a local certificate to the PKI entity. The CA then uses the PKI entity's public key to encrypt the certificate, and issues the certificate to the PKI entity. At the same time, the CA also sends the certificate to the certificate/CRL database.

6. The PKI entity receives the certificate from the CA.

   • If the PKI entity uses SCEP to apply for a local certificate, the PKI entity uses its own private key to decrypt the certificate and the CA's public key to decrypt the digital signature, and verifies the digital fingerprint. If the digital fingerprint is the same as its local one, the PKI entity accepts and installs the local certificate.

   • If the PKI entity uses CMPv2 to apply for a local certificate:

     • Additional certificate

       The PKI entity uses the private key corresponding to its additional certificate to decrypt the local certificate, uses the CA's public key to decrypt the digital signature, and verifies the digital fingerprint. If the digital fingerprint is the same as its local one, the PKI entity accepts and installs the local certificate.

     • MAC

       The PKI entity uses its own private key to decrypt the certificate and verifies the MAC reference value and secret value. If the reference value and secret value are the same as the local ones, the PKI entity accepts and installs the local certificate.

7. The PKI entities in a communication session need to obtain and install each other's local certificates. The PKI entities can download the peer's local certificates through HTTP or other modes. In special scenarios, such as IPsec application, the PKI entities proactively send their local certificates to the peer.

8. After the peer's local certificate is installed on the local end, the local end uses CRL or OCSP to check whether the peer certificate is valid.

9. The PKI entities use the public keys in peer certificates for secure communication only after they confirm that the peer certificates are valid.

If an RA is available in a PKI system, the PKI entities also need to download the RA's certificate. The RA verifies the local certificate enrollment messages from PKI entities, and forwards the messages to the CA after verifications are passed.