Detailed Explanation of PKI Terminology and Definitions

Last Updated: 2023-05-07

Page content

Public Key Infrastructure (PKI) definitions and terminologies.

PKI: Public Key Infrastructure

PKI stands for Public Key Infrastructure, and it is a system that enables secure communication over the internet by using public key cryptography. PKI is a collection of policies, procedures, hardware, software, and people that work together to create, manage, distribute, and revoke digital certificates and public-private key pairs.

In PKI, each entity has a public-private key pair, and the public key is published in a digital certificate, which is signed by a trusted third-party known as a Certificate Authority (CA). The CA acts as a trusted intermediary that verifies the identity of the entity requesting the certificate and signs the certificate to indicate that it is genuine.

PKI is used for a wide range of applications, such as secure email, secure web browsing, and digital signatures. PKI provides confidentiality, integrity, and authenticity for digital data by using encryption and digital signatures.

PKI is a complex system that requires careful planning, management, and maintenance. PKI infrastructure can include multiple CAs, certificate revocation lists (CRLs), and certificate management systems.

CA: Certificate Authority

In PKI, a Certificate Authority (CA) is a trusted entity that issues digital certificates and verifies the identity of the certificate holder. The CA acts as a trusted third party in the digital certificate authentication process and provides the necessary infrastructure to establish trust between parties in a secure communication.

The CA is responsible for verifying the identity of the certificate holder and ensuring that the certificate holder has the legal right to use the digital certificate. The CA also creates the digital certificate and signs it using its own private key, which provides the digital certificate with a trusted root of trust. The digital certificate includes information about the certificate holder, such as name, address, and public key, and is used to establish a secure connection between parties in a communication.

CAs are typically hierarchical in nature, with a root CA at the top of the hierarchy and multiple subordinate CAs beneath it. The root CA is the highest level of trust and is responsible for issuing digital certificates to subordinate CAs. Subordinate CAs are responsible for issuing digital certificates to end-users, such as individuals, organizations, or devices.

CAs play a critical role in PKI infrastructure and are essential for establishing trust in secure communication. However, CAs are also vulnerable to attacks, and a compromised CA can undermine the security of the entire PKI infrastructure. As a result, CAs must implement strict security measures, including physical security, access controls, and auditing, to ensure the integrity and confidentiality of the PKI infrastructure.

Root CA: Root Certificate Authority

In PKI, a Root Certificate Authority (CA) is the highest level of trust in the certificate hierarchy. It is the top-most CA in a certificate chain and is responsible for issuing digital certificates to subordinate CAs or directly to end-users.

The root CA is considered the ultimate source of trust and is responsible for establishing trust in the entire PKI infrastructure. The root CA is typically operated by a trusted third-party organization, such as a government agency, a commercial CA, or a non-profit organization. The root CA is also responsible for signing the certificates of subordinate CAs, thereby delegating trust to them.

The root CA’s public key is widely distributed, either as part of the operating system or web browser, or through other mechanisms such as certificate distribution points. When a client application receives a digital certificate signed by a subordinate CA, it can verify the certificate chain by checking that the subordinate CA’s certificate was signed by the root CA’s private key.

It is important to ensure that the root CA’s private key is kept secure and inaccessible to unauthorized parties. Compromise of the root CA’s private key can lead to the compromise of the entire PKI infrastructure, resulting in the loss of trust in all digital certificates issued by the PKI.

The root CA plays a critical role in the PKI infrastructure and is essential for establishing trust in secure communication. As such, it is subject to strict security measures, including physical security, access controls, and auditing, to ensure the integrity and confidentiality of the PKI infrastructure.

Intermediate CA: Intermediate Certificate Authority

In PKI, an Intermediate Certificate Authority (CA) is a subordinate CA that is responsible for issuing digital certificates to end-users or other subordinate CAs. Intermediate CAs are typically located between the root CA and end-user certificates in the certificate hierarchy.

Intermediate CAs are used to delegate trust from the root CA to end-users or other subordinate CAs. The root CA signs the certificate of the intermediate CA, thereby delegating trust to it. The intermediate CA can then issue digital certificates to end-users or subordinate CAs, which can be verified using the intermediate CA’s certificate chain.

Intermediate CAs provide an additional layer of security and flexibility to the PKI infrastructure. They allow for better management of digital certificates by enabling the creation of multiple levels of trust and by reducing the load on the root CA. Intermediate CAs can also be used to limit the scope of damage in the event of a compromise, as only the certificates issued by the compromised intermediate CA would be affected.

Like root CAs, intermediate CAs are subject to strict security measures, including physical security, access controls, and auditing, to ensure the integrity and confidentiality of the PKI infrastructure. It is important to ensure that the private key of the intermediate CA is kept secure and inaccessible to unauthorized parties, as compromise of the private key can lead to the compromise of the entire PKI infrastructure.

Public Certificate

In PKI, a public certificate is a digital document that contains information about a public key and its associated owner, such as a person, a device, or an organization. The certificate is issued by a trusted third-party called a Certificate Authority (CA) and signed using the CA’s private key to ensure the certificate’s authenticity.

A public certificate typically includes the following information:

The name of the certificate’s owner, also known as the Subject
The owner’s public key
The name of the CA that issued the certificate, also known as the Issuer
The digital signature of the CA, which verifies the certificate’s authenticity
The period of validity for the certificate
The intended usage of the public key, such as for encrypting data or verifying digital signatures

A public certificate is used to establish trust between two parties during secure communication over the internet. When a user connects to a secure website, for example, the website presents its public certificate to the user’s browser to establish a secure connection. The browser verifies the certificate’s authenticity by checking the signature of the CA that issued the certificate.

Public certificates are a critical component of PKI infrastructure and are used for various applications, including secure web browsing, email encryption, and digital signatures.

Private Key

In PKI, a private key is a secret key that is kept confidential by its owner and used to decrypt or sign digital information. The private key is mathematically related to its corresponding public key, which is published in a digital certificate.

A private key is used in conjunction with a public key to provide confidentiality, integrity, and authenticity for digital data. When a user encrypts a message using a public key, only the corresponding private key can decrypt the message. Similarly, when a user signs a message using a private key, the corresponding public key can verify the signature’s authenticity.

Private keys must be kept confidential and secure to ensure the integrity of the PKI infrastructure. If a private key is compromised, an attacker can use it to impersonate the owner and decrypt or sign digital information. Private keys are typically stored in a secure hardware device, such as a smart card or a hardware security module (HSM), or encrypted with a passphrase and stored on a secure storage device.

Private keys are a critical component of PKI infrastructure and are used for various applications, including secure web browsing, email encryption, and digital signatures.

To generate a private key using OpenSSL command-line tool, you can use the following command:

openssl genpkey -algorithm <key_type> -out <private_key_file>

Replace <key_type> with the type of key you want to generate (e.g. rsa:2048 for a 2048-bit RSA key), and <private_key_file> with the filename and path where you want to save the private key file.

When you run this command, OpenSSL will generate a private key using the specified algorithm and save it to the specified file location. The generated private key file will be in PEM format by default.

Note that this command will only generate the private key. To obtain a digital certificate that is signed by a CA, you will need to generate a CSR using the private key and submit it to a CA for signing.

Certificate Serial Number

In PKI (Public Key Infrastructure), a certificate serial number is a unique identifier assigned to each digital certificate issued by a Certificate Authority (CA). It is a non-random number that is associated with the public key contained in the certificate.

The serial number is typically a large integer that is generated by the CA at the time the certificate is issued. It is unique within the scope of the issuing CA, meaning that no two certificates issued by the same CA can have the same serial number.

The certificate serial number is an important component of a digital certificate because it serves as a means of identifying the certificate and distinguishing it from other certificates issued by the same CA. It is also used in certificate revocation lists (CRLs) to identify revoked certificates.

In OpenSSL, a certificate’s serial number can be viewed using the following command:

openssl x509 -in [certificate-file] -serial -noout

This command displays the certificate’s serial number in hexadecimal format. For example:

$ openssl x509 -in stg2_xs_wsecc.crt -serial -noout
serial=3AB45FB1EB15B48A82D3DA34841EC647

Overall, the certificate serial number is an essential part of PKI infrastructure as it provides a unique identifier for each digital certificate, helping to ensure the security and integrity of online communications.

Certificate Subject

In PKI (Public Key Infrastructure), the certificate subject is the entity to which the certificate is issued. It is a vital part of a digital certificate and typically contains information such as the name, email address, organization, and location of the certificate holder.

The certificate subject is also known as the distinguished name (DN) or the subject DN, which uniquely identifies the certificate holder. The subject DN consists of a series of attributes, such as country, state, city, organization name, organizational unit, and common name (CN). The common name is typically the domain name or hostname of the server or device to which the certificate is issued.

The certificate subject is used to verify the identity of the certificate holder and to establish a secure SSL/TLS (Secure Sockets Layer/Transport Layer Security) connection between the client and server. It is also used in certificate revocation lists (CRLs) to identify revoked certificates.

In OpenSSL, a certificate’s subject can be viewed using the following command:

openssl x509 -in [certificate-file] -subject -noout

This command displays the certificate’s subject in human-readable format. For example:

$ openssl x509 -in D-TRUST_BR_Root_CA_1_2020.crt -inform der -subject -noout
subject= /C=DE/O=D-Trust GmbH/CN=D-TRUST BR Root CA 1 2020

Overall, the certificate subject is an essential part of PKI infrastructure as it provides identification information for the certificate holder and helps to ensure the security and integrity of online communications.

Certificate Fingerprint

In PKI, a certificate fingerprint is a unique digital identifier that is used to verify the authenticity of a digital certificate. A certificate fingerprint is generated by applying a cryptographic hash function to the contents of the certificate, producing a fixed-length string of characters that uniquely identifies the certificate.

The certificate fingerprint can be used to verify the integrity of a certificate by comparing it to the known fingerprint of a trusted certificate. If the fingerprints match, it provides a high degree of assurance that the certificate is genuine and has not been tampered with.

There are several types of certificate fingerprints, including SHA-1, SHA-256, and MD5. However, SHA-256 is currently the most commonly used and recommended type of fingerprint, as it provides a higher level of security than other hash functions.

Certificate fingerprints can be obtained using various tools and utilities, such as OpenSSL and Keytool. They are often displayed in hexadecimal format and can be used by system administrators and security professionals to verify the authenticity of digital certificates and to detect any signs of tampering or forgery.

To get the certificate fingerprint using the OpenSSL command-line tool, you can use the following command:

openssl x509 -in <certificate_file> -noout -fingerprint

Replace <certificate_file> with the path to the certificate file for which you want to obtain the fingerprint. For example:

openssl x509 -in stg2_xs_wsecc.crt -noout -fingerprint
SHA256 Fingerprint=27:BF:AD:FB:25:68:47:C2:C4:01:6A:2F:FA:13:14:C8:4D:27:C1:73:A2:D2:48:B9:A2:98:8F:14:3A:30:42:60

This command will generate the SHA-256 fingerprint of the certificate by default. To generate a different type of fingerprint, you can specify the hash algorithm using the sha1, -sha256 or -md5 options. More examples:

Generate sha512 fingerprint:

$ openssl x509 -in stg2_xs_wsecc.crt -noout -fingerprint -sha512
SHA512 Fingerprint=2C:44:E0:DA:12:A5:0D:2C:C9:D3:D4:F8:C8:F5:AC:C6:80:33:4F:AC:C2:18:5F:BE:84:17:5D:27:17:87:E0:C2:65:A2:2E:5B:0B:71:AB:D5:2A:D9:8F:DC:0C:91:D8:C3:9F:51:40:24:47:4C:9E:1A:B3:65:0F:9E:71:5C:EC:D7

Generate md5 fingerprint:

$ openssl x509 -in stg2_xs_wsecc.crt -noout -fingerprint -md5
MD5 Fingerprint=E2:B3:07:9E:47:93:E4:2B:EA:8A:7F:85:2E:EC:8F:44

Generate sha1 fingerprint:

$ openssl x509 -in stg2_xs_wsecc.crt -noout -fingerprint -sha1
SHA1 Fingerprint=49:5E:1F:43:6E:FE:73:35:BC:30:26:2B:E1:0F:77:65:A3:61:0A:01

Signature Hash Algorithm

In PKI, a signature hash algorithm is a cryptographic hash function used to create a message digest from the content of a digital certificate or other digital data. The message digest is then signed using a private key, which generates a digital signature that can be verified using the corresponding public key.

The choice of signature hash algorithm can impact the security and interoperability of a PKI system. Commonly used signature hash algorithms include:

SHA-1: a widely used hash algorithm, but considered insecure due to vulnerabilities that have been discovered in recent years.
SHA-2: a family of hash algorithms that includes SHA-256, SHA-384, and SHA-512. Considered to be more secure than SHA-1.
MD5: an older hash algorithm that is now considered insecure due to vulnerabilities that have been discovered.
RIPEMD-160: a hash algorithm that is sometimes used in conjunction with other algorithms to create stronger signatures.

When selecting a signature hash algorithm, it’s important to consider factors such as security, compatibility with existing systems, and the specific use case of the PKI system. It’s also important to stay up to date with current best practices and recommendations from industry organizations like the CA/Browser Forum.

To view the signature hash algorithm used in a digital certificate, you can use the following OpenSSL command:

openssl x509 -in <certificate_file> -text -noout | grep "Signature Algorithm"

Replace <certificate_file> with the filename and path of the certificate you want to examine. For example:

$ openssl x509 -in stg2_xs_wsecc.crt -text -noout | grep "Signature Algorithm"
    Signature Algorithm: sha384WithRSAEncryption
    Signature Algorithm: sha384WithRSAEncryption

When you run this command, OpenSSL will display the signature algorithm used to sign the certificate, such as sha256WithRSAEncryption. This information can be useful for verifying the security and compatibility of the certificate in your PKI system.

CSR: Certificate Signing Request

A Certificate Signing Request (CSR) is a message generated by an applicant for a digital certificate, such as an SSL/TLS certificate, to request a certificate from a Certificate Authority (CA). The CSR contains information about the applicant’s identity, such as their name and domain name, as well as the public key associated with the certificate.

The process of obtaining a digital certificate typically begins with the generation of a CSR by the applicant. The CSR is then submitted to a CA, along with additional information that may be required to verify the applicant’s identity. The CA will then use the information in the CSR to issue a digital certificate, which can be used to authenticate the applicant’s identity and establish secure communication with other parties.

The CSR typically includes the following information:

The name of the applicant or organization requesting the certificate
The domain name or hostname associated with the certificate
The public key associated with the certificate Information about the encryption algorithm to be used with the certificate
Other relevant information about the certificate, such as the desired expiration date

The CSR is typically generated by the applicant using software provided by the CA or a third-party tool. Once the CSR is generated, it can be submitted to the CA for verification and issuance of the digital certificate.

To generate a CSR using OpenSSL command-line tool, you can use the following command:

openssl req -new -newkey <key_type> -keyout <private_key_file> -out <csr_file>

Replace <key_type> with the type of key you want to generate (e.g. rsa:2048 for a 2048-bit RSA key), <private_key_file> with the filename and path where you want to save the private key file, and <csr_file> with the filename and path where you want to save the CSR file.

When you run this command, you will be prompted to enter various pieces of information, such as the Common Name (CN) of the entity for which you are requesting the certificate, as well as optional information such as organization name, country code, etc.

Once you have provided all the necessary information, the CSR and private key files will be generated and saved to the specified locations. You can then submit the CSR to a CA to obtain a digital certificate.

CRL: Certificate Revocation List

In PKI, a Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the Certificate Authority (CA) before their scheduled expiration date. The CRL is signed by the CA and made available to clients that need to verify the authenticity of digital certificates.

A CRL contains information about revoked certificates, such as the serial number of the certificate, the date and time of revocation, and the reason for revocation. When a client receives a digital certificate, it checks the certificate’s serial number against the CRL to ensure that the certificate has not been revoked.

CRLs play a critical role in ensuring the security and integrity of PKI infrastructure. If a digital certificate is compromised or the owner’s private key is lost, the CA can revoke the certificate and add it to the CRL. Clients can then download the updated CRL to ensure that they do not accept a compromised certificate.

CRLs can be published by the CA on a regular basis, such as daily or weekly, and can be distributed in various formats, such as X.509, LDAP, or HTTP. Some PKI infrastructures also use Online Certificate Status Protocol (OCSP) to provide real-time information about the status of digital certificates.

CRLs can be large and may require significant network bandwidth to download and distribute. As a result, some PKI infrastructures use delta CRLs, which contain only the changes since the last CRL, to reduce network traffic and improve performance.

OCSP: Online Certificate Status Protocol

In PKI, Online Certificate Status Protocol (OCSP) is a protocol used to verify the status of digital certificates in real-time. OCSP provides a more efficient and faster way to check the revocation status of a digital certificate compared to Certificate Revocation Lists (CRLs).

When a client receives a digital certificate, it sends a request to the OCSP responder to check the certificate’s status. The OCSP responder then sends a signed response to the client indicating whether the certificate is valid, revoked, or unknown. The response is signed using the responder’s private key and can be verified by the client using the responder’s public key.

OCSP can provide real-time revocation status information for a single certificate, whereas CRLs provide status information for a large number of certificates. This makes OCSP more efficient for checking the status of individual certificates, especially in high-volume environments.

OCSP responders can be operated by the Certificate Authority (CA) or a third-party service provider. Some PKI infrastructures also use OCSP stapling, which allows the web server to include the OCSP response with the certificate during the TLS handshake, reducing the number of round trips required to establish a secure connection.

OCSP is widely used in PKI infrastructures to ensure the security and integrity of digital certificates. It is supported by most modern web browsers and can be used for various applications, including secure web browsing, email encryption, and digital signatures.

PEM

PEM stands for “Privacy Enhanced Mail,” and it is a base64 encoded format that is used to store digital certificates and private keys. It is a widely used format for certificates, especially in web servers such as Apache and Nginx. PEM format files typically have a file extension of .pem or .crt.

PEM format files can contain multiple certificates or keys concatenated together. They typically start with a header that identifies the type of content that follows, such as “—–BEGIN CERTIFICATE—–” for a certificate, or “—–BEGIN RSA PRIVATE KEY—–” for a private key. The content itself is base64 encoded and enclosed between the header and footer, which is identified by “—–END CERTIFICATE—–” or “—–END RSA PRIVATE KEY—–” respectively.

PEM format files can be opened and viewed with a text editor, but they should be treated as sensitive information and stored securely.

To decode a PEM-encoded certificate, you can use the openssl command-line tool. Here’s an example command:

openssl x509 -in certificate.pem -text

This command specifies that the input file (-in) is in PEM format and should be decoded as an X.509 certificate (x509). The -text option tells OpenSSL to print the decoded information in human-readable form.

Replace certificate.pem with the actual file name of your PEM-encoded certificate.

DER

DER stands for “Distinguished Encoding Rules,” and it is a binary format used to store digital certificates and other X.509-based public key infrastructure (PKI) entities. DER certificates are widely used in embedded systems and applications that require a smaller footprint due to their compact size.

Unlike PEM format, DER format does not use base64 encoding and consists of a series of binary data. DER certificates have a file extension of .der or .cer and can be opened with a hex editor to view their content.

DER certificates are less commonly used in web servers compared to PEM format. However, they are used in situations where a smaller certificate size is required, such as in smart cards, mobile devices, and other embedded systems.

To decode a DER-encoded certificate, you can use the openssl command-line tool. Here’s an example command:

openssl x509 -inform der -in certificate.der -text

This command specifies that the input file (-in) is in DER format (-inform der) and should be decoded as an X.509 certificate (x509). The -text option tells OpenSSL to print the decoded information in human-readable form.

Replace certificate.der with the actual file name of your DER-encoded certificate.

CA/Browser Forum

The CA/Browser Forum is a consortium of certificate authorities (CAs) and browser vendors that works to establish best practices and standards for digital certificates and web security. The CA/Browser Forum was formed in 2005 by representatives of major CAs and browser vendors, and has since become a leading authority in the field of PKI.

The CA/Browser Forum sets guidelines and standards for the issuance and management of digital certificates, including requirements for the verification of the identity of the certificate holder, the security of the private key, and the revocation of certificates in the event of compromise or misuse. These guidelines are intended to ensure the integrity and security of digital certificates and to promote trust in the PKI infrastructure.

The CA/Browser Forum also maintains a list of approved CAs, which are trusted by major web browsers such as Google Chrome, Mozilla Firefox, and Microsoft Edge. The approved CAs must adhere to the guidelines and standards set by the CA/Browser Forum and are subject to regular audits to ensure compliance.

In addition to setting standards for digital certificates and web security, the CA/Browser Forum also works to promote the adoption of new technologies and protocols that enhance web security. For example, the CA/Browser Forum played a key role in the adoption of Certificate Transparency, a protocol for detecting and preventing fraudulent or malicious certificates.

The work of the CA/Browser Forum has helped to improve the security and reliability of online communication and commerce, and has established trust in the PKI infrastructure. By setting standards and guidelines for digital certificates and web security, the CA/Browser Forum has helped to reduce the risk of fraud and data breaches, and has promoted a more secure and trustworthy online environment.

CP: Certificate Policy

In PKI (Public Key Infrastructure), a Certificate Policy (CP) is a set of rules and guidelines that govern the issuance, management, and use of digital certificates by a Certificate Authority (CA). The CP defines the requirements for issuing and using certificates, as well as the roles and responsibilities of all parties involved in the PKI infrastructure.

The Certificate Policy document is typically published by the CA and outlines the following information:

The purpose and scope of the CP.
The legal and regulatory framework under which the CA operates.
The procedures for issuing, managing, and revoking certificates.
The security requirements for the issuance and use of certificates.
The identification and authentication requirements for certificate holders.
The standards and protocols used by the CA to manage and distribute certificates.
The audit and compliance requirements for the CA and certificate holders.
The liability and dispute resolution procedures for the CA and certificate holders.
The Certificate Policy is an essential component of a PKI infrastructure, as it provides a framework for ensuring the security and integrity of digital certificates and the trustworthiness of the PKI system as a whole.

In OpenSSL, the Certificate Policy can be viewed using the following command, which displays the certificate’s metadata, including the Certificate Policy information.

openssl x509 -in [certificate-file] -text -noout

Overall, the Certificate Policy is a critical document that outlines the rules and guidelines for issuing and managing digital certificates in a PKI infrastructure, ensuring the trust and security of online communications.

CPS: Certificate Practice Statement

In PKI (Public Key Infrastructure), a Certificate Practice Statement (CPS) is a document that outlines the specific practices and procedures that a Certificate Authority (CA) follows when issuing, managing, and revoking digital certificates. The CPS provides a detailed description of the technical and administrative procedures used by the CA, including the policies, practices, and protocols related to the issuance and management of digital certificates.

The CPS is intended to provide transparency and accountability in the issuance and management of digital certificates by the CA. The CPS document typically includes the following information:

The CA’s name, location, and contact information.
The CA’s certificate issuance and management policies and procedures.
The CA’s identification and authentication procedures for verifying the identity of certificate applicants.
The technical requirements for certificate issuance and management, such as cryptographic algorithms and key lengths.
The CA’s revocation policies and procedures.
The procedures for handling security breaches and incidents.
The procedures for complying with legal and regulatory requirements.
The liability and indemnification provisions related to the issuance and management of certificates.
The CPS is an essential component of a PKI infrastructure, as it provides transparency and accountability in the issuance and management of digital certificates. It also provides a mechanism for customers and other interested parties to verify that the CA is following industry best practices and adhering to regulatory requirements.

Overall, the Certificate Practice Statement is a critical document that outlines the specific practices and procedures followed by a CA when issuing and managing digital certificates, providing transparency and accountability in the PKI infrastructure.