Public Key Infrastructure (PKI) is the collection of technologies that are used to provide authentication, integrity and confidentiality to user on a network.
Additionally, PKI can be defined as the a set of the rules, procedures, hardware and software and persons that are used to manage digital certificates.
PKI is used to established Trust between devices on a network.
In PKI, the Public Key is usually associated with a Digital Signature to add trust and validate details about the owner of the certificate.
Generation of the Key - Cipher and Key size.
Certificate generation - The Digital certificate is created and assigned to a person or device.
Distribute - The key is distributed to the person or the device.
Storage - The key is stored in a secure location to prevent unauthorized usage.
Revocation - A certificate or key may be revoke if it is compromised by a threat actor.
Expiration - Each certificate has a lifespan.
A Digital Certificate is created when a Key and a Digital Signature is combined.
The certificate will contain details about the certificate owner such as the organization.
A digital certificate can be self-generated or obtained from a trusted Certificated Authority (CA).
Digital certificates uses a standard format which is the X.509 standard:
Version
Serial number
Signature Algorithm
Issuer
Valid From
Valid To
Subject
Public Key
Extensions
The Certificate Authority is responsible for creating or generating a Key.
The CA will create a Public and Private Key pair.
The Private Key is to be installed on the public server and the Public Key is sent to the CA to be signed. This is referred to as a Certificate Signing Request (CSR).
In some environments, there may a Single CA which is 1 certificate authority which will create digital certificates for all devices within the network or organization.
In a Hierarchical deployment, a Single CA can create certificates for Intermediate CA. The Intermediate CA can then distribute certificates to devices.
This is a list maintained by the Certificate Authority
The Certificate Authority (CA) will always has a list of all revoked certificates.
A web browser uses the OCSP to check the status of a Digital Certificate.
Therefore, if a certificate is not valid the browser will provide a warning.
In a Hierarchical deployment of a Certification Authorities, the Root CA can create certificates for each Intermediate CA.
Each Intermediate CA can create certificate for devices which requires a certificate.
Therefore the Root CA can be offline to prevent any cyber-attacks to it.
Since a web browser has to use the OCSP to determine the status a certificate by a CA, the information can be stapled onto the certificate itself.
This allows the certificate holder such as a PC to verify the status of a certificate on its own.
In a Man-in-the-Middle attack, the attacker is able to intercept and modify any message such as a certificate.
With pinning, the certificate is usually embedded or hardcoded into an application.
The application will when download a copy the certificate from the server and compare the certificate with the certificate that is hardcoded to determine if a match is found.
If a match is found, the application will know it is communicating with the server and the communication is trusted.
Single CA
Hierarchical CA
Mesh
Web of Trust
Mutual Authentication - Client trust the certificate from the server and the Server trust the certificate from the client.
Key escrow allows someone or something else such as a 3rd party to hold the key.
The Chain of Trust of certificates between all the servers and the Root Certificate Authority (CA).
The first device is the Root CA which issues certificates to Intermediate CAs.
A wildcard certificate is created based on the server's name.
A wildcard certificate is usually applied to all the sub-domains or all the server names in a domain.
Subject Alternative Name (SAN) certificate
Uses the X.509 standard
Provides more details such identity information the certificate
Allows a certificate to support multiple domains on a web server
Code signing certificate is used to digitally signed a software to provide trust to the user who is installing an application.
If the certificate is not validated, the software should not be trusted.
This a certificate that is created by an internal device such as an internal web server.
Creating a self-signed certificate allows an organization to create and distribute their own certificates.
This self-signed certificate will be required to be installed on all devices within the company.
This type of certificate is installed on a device that was created by your trusted Certificate Authority (CA)
This certificate is used to provide trust between client devices and the rest of the network.
Email certificates are used to encrypt messages.
The Public Key of the recipient is used encrypt an email message while the recipient's Private Key is used to decrypt the message.
Certificates can be assigned to a user.
An example is a digital certificate installed on a user's smart card to provide authentication of the user.
The Root certificate is the created by the Root Certificate Authority.
The Root CA will then issue Intermediate certificates to Intermediate CA.
The Root certificate will allow a device such as the Root CA to create any trusted certificate and therefore it should always be kept safe.
This type of certificate is used to validate the owner of the certificate and the owner has authority over a domain name.
This certificate performs further validation of the certificate's holder identity.
If the owner is validated, the browser will provide a green name on the address bar. This is an indication of an EV certificate.
Most commonly the X.509 format is used to format the details within a Digital Certificate.
This is a variation of the X.509 format
The information was presented in a binary format
The information within the certificate uses the ASCII format
On Microsoft Windows operating system, a Digital Certificate is usually has the .cer extension.
This is another format of the X.509 format but for Windows devices.