🔐Public Key Infrastructure (PKI)
Public Key Infrastructure (PKI) is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
It's a framework that establishes secure communication through authentication, encryption, and data integrity.
Here's how PKI works to facilitate secure communication:
Key Pair Generation: In PKI, each participant has a pair of cryptographic keys - a public key and a private key. The public key is made freely available to anyone who might want to send you a message. The private key is kept secret, so only you know it. Certificate Issuance: A digital certificate, similar to an identity card, is issued by a trusted party known as the Certificate Authority (CA). This certificate contains the public key and identifies who owns it (and other information like the issuer, the owner's name, the certificate validity period). Certificate Distribution: The issued certificate is distributed and can be freely accessed by anyone needing to communicate with the certificate owner. Verification and Trust: When someone wants to send a secure message to the certificate owner, they can get the owner's public certificate, which contains the public key. They can verify the certificate is valid and trusted by checking the digital signature of the CA on the certificate. Secure Communication: The sender uses the recipient's public key to encrypt the message. The recipient can then use their private key to decrypt the message and read it. In this way, secure communication is achieved. If the private key is kept secret, only the recipient can decrypt the message. PKI is important for several reasons:
Authentication: PKI enables the verification of the identity of a person or a device, ensuring the entity you're communicating with is indeed who they claim to be. Data Integrity: PKI ensures that the data has not been tampered with during transmission. Any alteration of the data can be detected. Confidentiality: PKI provides confidentiality by encrypting data. Only the intended recipient can decrypt and access the data. Non-repudiation: PKI provides a mechanism for non-repudiation, meaning the sender cannot deny the authenticity of their signature on a document or the sending of a message that they originated. In essence, PKI is a crucial component in securing communications in today's digital world, especially for activities like e-commerce, online banking, and confidential email.
In a Public Key Infrastructure (PKI) system, trust is established through the use of a hierarchy of trusted entities.
Two of the most important entities in this hierarchy are the Certificate Authority (CA) and the Registration Authority (RA). 🔑Key Management
The Key Management lifecycle involves the generation, distribution, storage, usage, and eventual destruction of cryptographic keys. It is a critical aspect of security management, as the strength of many security controls depends on the secrecy and handling of these keys.
Because cryptographic keys contain information essential to the security of the cryptosystem, it is incumbent upon cryptosystem users and administrators to take extraordinary measures to protect the security of the key.
This lifecycle ensures that the keys are generated, used, stored, and retired securely.
Here's a breakdown of the key management lifecycle:
Key Generation: This is the first stage of the lifecycle. A pair of cryptographic keys is generated - a public key and a private key.
The public key is made available to anyone who might want to send you a message. The private key is kept secret, so only you know it. Key Distribution: Once the keys are generated, they need to be distributed securely.
The public key is typically embedded in a digital certificate and can be freely distributed, while the private key must be kept secret and secure. Key Storage: The keys, especially the private key, must be stored securely to prevent unauthorized access.
This often involves secure cryptographic hardware devices known as Hardware Security Modules (HSMs). Key Usage: The keys are used for their intended purposes, such as encryption, decryption, digital signing, and signature verification.
The usage of keys is governed by policies defined in the PKI. Key Backup: The private key is often backed up and securely stored to prevent data loss.
The backup process must be secure to prevent the private key from being exposed. Key Rotation: Over time, keys are rotated, meaning a new pair of keys is generated, and the old keys are retired.
This is done to limit the amount of data encrypted with a single key and to mitigate the risk if a key is compromised. Key Expiry: Keys have a defined validity period after which they expire. After expiration, the keys are no longer trusted for use.
Key Revocation: If a key is compromised or the user's access rights are changed, the key can be revoked before it expires.
A Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) is used to check the revocation status of keys. Key Destruction: Once a key has expired or been revoked, it is destroyed, ensuring it cannot be used in the future.
🚓Certificate Authority
The Certificate Authority is a trusted entity that issues digital certificates in a Public Key Infrastructure (PKI) system.
The role of the CA is crucial in establishing trust in the system, as it is responsible for verifying the identity of entities (which could be users, computers, networks, or services) before issuing them a certificate. Certificate authorities (CAs) are the glue that binds the public key infrastructure together. These neutral organizations offer notarization services for digital certificates. To obtain a digital certificate from a reputable CA, you must prove your identity to the satisfaction of the CA If you don't recognize and trust the name of the CA that issued the certificate, you shouldn't place any trust in the certificate at all. PKI relies on a hierarchy of trust relationships. If you configure your browser to trust a CA, it will automatically trust all of the digital certificates issued by that CA.
⛓️Intermediate CA
An Intermediate Certificate Authority (Intermediate CA), also known as a Subordinate CA, is a Certificate Authority (CA) that is certified by a Root CA or another Intermediate CA.
The Intermediate CA can issue certificates, but it's not the ultimate trust anchor of the PKI hierarchy. That role belongs to the Root CA. The use of Intermediate CAs adds an additional layer of security to the PKI system. Here's how:
Security: The private key of the Root CA is the most critical part of the PKI because it's used to sign all the Intermediate CA certificates. If the Root CA's private key is compromised, the entire trust chain is broken. Organizational Structure: Intermediate CAs can be used to reflect the organizational structure or to separate different operational domains. For example, a large corporation might have different Intermediate CAs for different departments or geographical locations. Revocation: If an Intermediate CA is compromised, the Root CA can revoke its certificate. This revocation is much less disruptive than having to revoke the Root CA's certificate, which would invalidate all certificates in the PKI.
🔗Certificate Chaining
Certificate Chaining, also known as the Chain of Trust, is a process used in Public Key Infrastructure (PKI) to verify the validity of a digital certificate.
It involves a series of certificates, each one certifying the one before it, leading back to a trusted Root Certificate Authority (CA). Here's how it works:
End-Entity Certificate: This is the certificate of the server or client you're communicating with. It's issued by an Intermediate CA or sometimes directly by the Root CA. Intermediate Certificates: These are certificates of Intermediate CAs. An Intermediate CA is certified by another Intermediate CA or the Root CA. There can be multiple levels of Intermediate CAs. Root Certificate: This is the certificate of the Root CA. The Root CA is the most trusted entity in the PKI, and its certificate is self-signed. When a secure connection is established (for example, during an HTTPS session), the server presents its certificate chain to the client. The chain includes the server's certificate (end-entity certificate) and any necessary intermediate certificates, up to but not including the root certificate.
The client then verifies the chain:
It checks the digital signature on the server's certificate using the public key in the Intermediate CA's certificate. It then checks the digital signature on the Intermediate CA's certificate using the public key in the next certificate up the chain. This process continues until it reaches the Root CA's certificate. The Root CA's certificate is self-signed, so the client checks the digital signature using the public key in the same certificate. The client already has a copy of the Root CA's certificate (or should have, if it's a trusted Root CA), so it can trust that the public key is valid. If all the digital signatures check out, then the client can trust the server's certificate and establish a secure connection.
This chain of trust is crucial in PKI systems to ensure secure and trusted communication.
®️Registration Authority
Registration Authorities are entities that acts as a verifier for the CA. While the CA is responsible for issuing certificates, it may delegate the task of verifying the identity of entities to the RA.
The RA performs the necessary checks to validate the identity of entities, and then passes the verified requests to the CA for certificate issuance. The RA does not issue certificates itself. The use of an RA can be beneficial in large organizations or complex systems where the process of identity verification is resource-intensive and needs to be distributed. The RA can handle the front-end tasks of identity verification, while the CA can focus on the back-end tasks of certificate issuance and management. In summary, the CA and RA work together to establish trust in a PKI system. The CA issues trusted certificates, and the RA verifies the identity of entities to ensure that certificates are issued to the correct entities.
💥Certificate Generation and Destruction
🚨Certificate Revocation List (CRL)
A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date.
There are several reasons why a certificate might be revoked, such as:
The certificate was compromised (for example, the certificate owner accidentally gave away the private key). The certificate was erroneously issued (for example, the CA mistakenly issued a certificate without proper verification). The details of the certificate changed (for example, the subject's name changed). The security association changed (for example, the subject is no longer employed by the organization sponsoring the certificate). A CRL is a simple way for a client to check whether a certificate is still valid. When a secure connection is being established, the client can download the latest CRL from the CA and check whether the certificate of the server it's connecting to is listed there.
If the certificate is on the CRL, the client knows it has been revoked and can refuse to establish a connection. Cons of CRLs:
Size: For a large CA, the CRL can become very large, which makes it slow to download and process. Update Frequency: The CRL is only as up-to-date as its last update. If a certificate is revoked just after the CRL is updated, the revocation won't be known until the next update. Network Overhead: Every client needs to download the entire CRL, even if it only needs to check one certificate. This can lead to unnecessary network traffic. Latency: The need to download and process the CRL can slow down the establishment of secure connections. Because of these cons, many systems now use the Online Certificate Status Protocol (OCSP) as an alternative to CRLs. OCSP allows a client to query the CA about the status of a single certificate, which can be faster and more efficient.
🫵🏿Online Certificate Status Protocol (OCSP)
This protocol eliminates the latency inherent in the use of certificate revocation lists by providing a means for real-time certificate verification.
When a client receives a certificate, it sends an OCSP request to the CA's OCSP server. The server then responds with a status of valid, invalid, or unknown. The browser uses this information to determine whether the certificate is valid. It is a more efficient alternative to using Certificate Revocation Lists (CRLs), so it has mostly replaced CRLs. OCSP has several advantages over CRLs:
Efficiency: Instead of downloading potentially large CRLs and searching through them for a specific certificate, the client simply asks the OCSP responder about the one certificate it's interested in. Timeliness: OCSP responses can be updated at any time, providing more timely information than a CRL, which is updated periodically. Scalability: OCSP is more scalable for large deployments because it reduces network bandwidth and client processing time compared to downloading and processing CRLs.
📎Certification Attributes
Digital certificates contain specific identifying information, and their construction is governed by an international standard—X.509.
Certificates that conform to X.509 contain the following certificate attributes:
Subject: This is the name of the entity that the certificate represents. This could be a person, a computer, a network device, or an organization. The subject is usually represented as a Distinguished Name (DN) in X.500 format, which includes components like Common Name (CN), Organizational Unit (OU), Organization (O), Locality (L), State (ST), and Country (C). Issuer: This is the entity that issued the certificate, usually a Certificate Authority (CA). Like the subject, the issuer is represented as a Distinguished Name. Validity Period: This includes the "Not Before" and "Not After" dates, which define the time period during which the certificate is valid. Public Key: This is the public key of the entity. It's used in the encryption and decryption process and for verifying digital signatures. Signature Algorithm: This is the algorithm used by the CA to sign the certificate. Signature: This is the digital signature of the issuer. The signature is created by taking a hash of the certificate and then encrypting it with the issuer's private key. It can be verified using the issuer's public key. Serial Number: This is a unique number assigned by the CA to the certificate. It's used to identify the certificate.
📝Certificate Signing Request (CSR)
A Certificate Signing Request (CSR) is a crucial component in the Public Key Infrastructure (PKI). It's used when an entity (like a person, server, or organization) wants to obtain a digital certificate from a Certificate Authority (CA).
The CA next creates an X.509 digital certificate containing your identifying information and a copy of your public key.
The CA then digitally signs the certificate using the CA's private key and provides you with a copy of your signed digital certificate. You may then safely distribute this certificate to anyone with whom you want to communicate securely.
🗨️Common Name (CN)
CN stands for Common Name. It is an attribute used in the Distinguished Name (DN) of a digital certificate. The DN is a string that uniquely identifies an entity (like a person, a server, or an organization) in a X.509 certificate, which is commonly used in SSL/TLS and other PKI (Public Key Infrastructure) systems.
The Common Name usually holds the fully qualified domain name (FQDN) of a server, such as "". It can also contain an individual's name, a company name, or an email address, depending on the use case of the certificate. When a client (like a web browser) connects to a server over a secure connection (like HTTPS), it checks that the CN in the server's certificate matches the server's actual domain name. If they don't match, the client will typically show a warning to the user, because this could indicate a man-in-the-middle attack.
📒Subject Alternative Name
The Subject Alternative Name (SAN) is an extension to the X.509 specification that allows for additional, or alternative, domain names to be associated with a single SSL certificate.
This is an improvement over the Common Name (CN) attribute, which allows for only one domain name to be specified. Here are some reasons why SAN is considered better than CN:
Multiple Domain Names: The most significant advantage of SAN is that it allows a single certificate to secure multiple domain names, also known as multi-domain SSL. This is not possible with the CN attribute, which can only hold one domain name.
🥛Expiration
Expiration refers to the end of a certificate's validity period. Each certificate is issued with a specific validity period, which includes a start date (also known as the "not before" date) and an end date (the "not after" date).
The expiration of a certificate is a critical aspect of maintaining trust and security in a PKI system.
When a certificate expires, it must be renewed, which typically involves generating a new key pair and requesting a new certificate from the CA.
📚Types of Certificates
Root Certificate: This is a self-signed certificate that identifies the Root Certificate Authority (CA). It's at the top of the certificate chain of trust. All other certificates are, directly or indirectly, validated against the root certificate. Intermediate Certificate: These are certificates that are used to sign other certificates but are themselves signed by the root certificate or another intermediate certificate. They form a chain of trust between the root certificate and end-entity certificates. End-Entity (or Leaf) Certificate: These are the certificates that are used in day-to-day operations like securing a website with HTTPS or signing a software application. They are signed by a root or intermediate certificate and do not sign other certificates. Wildcard Certificate: This is a type of SSL certificate that allows you to secure multiple subdomains of a domain with a single certificate. For example, a wildcard certificate for *.example.com could be used to secure www.example.com, mail.example.com, etc. SAN (Subject Alternative Name) Certificate: Also known as a multi-domain SSL certificate, a SAN certificate allows you to secure multiple different domain names with a single certificate. For example, a single SAN certificate could secure www.example.com, www.example.net, and www.example.org. Code Signing Certificate: This type of certificate is used to sign software applications and scripts. It allows the end user to verify that the software is from a known developer and hasn't been tampered with. Email (or S/MIME) Certificate: This type of certificate is used to secure email communication. It allows the sender to sign and encrypt email messages and the recipient to verify the sender's identity and decrypt the message. Self-Signed Certificate: This is a certificate that is not signed by a CA but by the entity itself. They are not inherently trusted by clients and are often used in testing environments or for internal use. EV (Extended Validation) SSL Certificate: This is a type of SSL certificate where the issuing CA verifies the legal entity controlling the website. Browsers may display the company name in the address bar, providing a higher level of trust to the user. Machine/Computer Certificate: A machine or computer certificate is a type of digital certificate that is used to authenticate a machine on a network. This can include servers, workstations, or any other device that can connect to a network. Domain Validation (DV) Certificates: are a type of SSL/TLS certificate used to secure web traffic. They provide the lowest level of validation offered by Certificate Authorities (CAs). When a CA issues a DV certificate, it verifies that the person or organization requesting the certificate has control over the domain name in the certificate. A User Certificate: also known as a client or personal certificate, is a type of digital certificate used in Public Key Infrastructure (PKI) to authenticate an individual user on a network or to a service. User certificates are issued by a trusted Certificate Authority (CA) and contain information about the user, such as their name or email address, as well as a public key. They also contain the digital signature of the CA, which allows other entities to verify the certificate's authenticity.
🌐Web Server SSL Certificate Types
There are four main types of SSL/TLS certificates that can be used to secure a web server:
Domain Validation (DV) Certificates: These are the simplest and most common type of SSL certificate. They provide a basic level of security by validating that the person or organization applying for the certificate has control over the domain name. The Certificate Authority (CA) verifies this by sending an email to an address associated with the domain or asking the requester to create a specific DNS record or file on the web server. DV certificates are typically issued quickly and are the least expensive type of SSL certificate. Organization Validation (OV) Certificates: OV certificates provide a higher level of security than DV certificates. In addition to validating domain ownership, the CA also verifies some information about the organization, such as its name and location. This information is included in the certificate and can be viewed by visitors to the website. OV certificates are more expensive and take longer to issue than DV certificates because of the additional validation steps. Extended Validation (EV) Certificates: EV certificates provide the highest level of security. The CA performs extensive checks to verify the organization's identity and legitimacy, including verifying its legal, physical, and operational existence, and the authority of the person requesting the certificate. The organization's name is displayed in the address bar of most browsers, providing a visual indication of the website's security. EV certificates are the most expensive type of SSL certificate and take the longest to issue. Wildcard Certificates: Wildcard certificates can secure a domain and an unlimited number of its subdomains. For example, a wildcard certificate for *.example.com could secure www.example.com, mail.example.com, blog.example.com, etc. Wildcard certificates can be DV, OV, or EV, depending on the level of validation provided. Each type of SSL certificate provides a different level of security and is suitable for different use cases, depending on the sensitivity of the data being handled by the website and the level of trust required by its users.
🗞️Certificate Formats
Digital certificates are stored in files, and those files come in a variety of different formats, both binary and text-based.
3.9 Given a scenario, implement public key infrastructure
