Public Key

Infrastructure
In-depth
Presentation by the Cyber
Team
Introduction to PKI

Public Key Infrastructure (PKI) is a framework that provides

secure communication and transactions over a network. It
consists of roles, policies, hardware, software, and procedures
needed to create, manage, distribute, use, store, and revoke
digital certificates and manage public-key encryption.
PKI enables the use of asymmetric cryptography, where a pair
of mathematically related keys - a public key and a private
key - are used for encryption and decryption, ensuring the
confidentiality, integrity, and authenticity of digital
communications.
Entities involved in PKI

• Certificate Authority (CA): A trusted third-party organization responsible for issuing

and revoking digital certificates. CAs verify the identity of certificate applicants and
digitally sign issued certificates to attest to their authenticity.
• Certificate Repository: A database or directory where issued certificates are
stored. This can be a centralized repository or distributed across multiple locations.
• Certificate Revocation List (CRL): A list maintained by the CA that contains the
serial numbers of certificates that have been revoked before their expiration dates.
• End Entity: Also known as a certificate subject or subscriber, an end entity is an
individual, device, or system that uses digital certificates for authentication,
encryption, or digital signatures. This can include secure websites, e-commerce
platforms, software developers and software distribution platforms.
Stages of PKI

In PKI, an applicant must go through different stages to gain

a digital certificate from the CA. The following stages include:
1. Certificate Signing Request Generation
2. Key Pair Generation
3. Submitting the CSR to the Certificate Authority
4. Verification by the CA
5. Issuance of the Digital Certificate by the CA
6. Installing the Digital Certificate
7. Certificate Revocation Checking
Certificate Signing Request (CSR)
Generation

Before an individual or organization can apply for a digital certificate,

they must first generate a Certificate Signing Request (CSR). A CSR is a
file containing information about the entity requesting the certificate.
The CSR acts as a formal application by the applying entity to a
Certificate Authority to request a digital certificate.
A CSR can be generated using software provided by a hosting provider
or a command-line tool like OpenSSL. During generation, the entity
applying will have to provide information about themselves such as
their name, organization or domain name.
While the CSR is being created, a process known as Key Pair Generation
is also automatically carried out, resulting in the generation of a public
and private key both of which belong to the applying entity.
Key Pair Generation
This is a process which involves the generation of public and private keys that are used to
encrypt/decrypt data, create digital signatures and authenticate secure communications. This
process involves several stages including:
1. Initialization: The key pair generation process begins with initializing the cryptographic algorithm that will
be used to generate the keys. Common algorithms include RSA (Rivest-Shamir-Adleman) and ECC (Elliptic
Curve Cryptography).
2. Random Number Generation: Cryptographically secure random numbers are generated to create the key
pair. These random numbers are essential for ensuring the unpredictability and uniqueness of the keys.
3. Key Length Selection: The length of the keys is determined based on the cryptographic requirements and
security standards. Longer key lengths typically provide higher security but may also require more
computational resources.
4. Prime Number Generation (for RSA): In RSA key generation, two large prime numbers are generated.
These prime numbers are used as part of the mathematical calculations to create the public and private
keys.
5. Key Pair Calculation: Using the generated random numbers and, if applicable, prime numbers, the public
and private keys are calculated according to the chosen cryptographic algorithm. The public key is derived
from the private key, ensuring that they are mathematically linked.

Note: The keys generated in this process are in their raw form and not encrypted. While the public
key does not need to be encrypted as it is shared freely with other entities that they themselves can
use to sign data that is only meant for the applying entity to receive, it is advised for the applying
Submitting the CSR to the CA

After the public and private keys are generated, the

public key is then encoded into the CSR in a specific
format such as X.509. This format ensures that the
public key is structured in a way that can be
understood by CAs or any other systems that
process requests. The CSR is then sent by the
applying entity to the CA for validation and
verification.
Verification by the CA

Upon receiving the CSR, the CA then performs validation checks on

the CSR to ensure its authenticity and accuracy. These can include:
• Verifying the domain ownership of an entity submitting the CSR by using
email-based verification, DNS record checks or HTTP file-based
authentication
• Verifying an organization by requesting official documentation such as
business licenses, articles of incorporation or legal opinions to confirm the
organization's identity and legitimacy
• Verifying the public key provided in the CSR by checking if it conforms to
expected formats (e.g., RSA or ECC) and meets minimum length
requirements
Issuance of the Digital Certificate by the
CA

After the CA verifies the CSR of an applying entity, the CA generates

a digital certificate. This digital certificate contains information such
as the entity's identity, the public key associated with the certificate,
the certificate's validity period and other relevant details.
The CA then signs the digital certificate with its own private key. This
is done to serve as cryptographic proof of the certificate's
authenticity, integrity and that the certificate has not been
tampered with since it was issued.
The CA then delivers the signed digital certificate to the entity that
requested it usually via email, a secure online portal or another
trusted communication channel.
Installing the Digital Certificate

Upon receiving the signed digital certificate, the entity then installs
the certificate on the server or device where it will be used.
The process typically involves copying the certificate file into the
server/device and configuring the server software (e.g., Apache,
Nginx) to use it. Server configuration can involve specifying the path
to the certificate file in the server's configuration files.
After configuring the server software, it's often necessary to restart
the server to apply the changes and use the new certificate file for
encrypted connections.
Testing will then be done to ensure that the encrypted connections are
working properly. This can be done by accessing the server via HTTPS
and checking for any browser warnings or errors.
Certificate Revocation Checking

The entity periodically checks for certificate

revocation to ensure that the certificate remains
valid.
If the certificate is ever compromised or no longer
needed, the entity can request its revocation from
the CA, and the CA will add the certificate to its
certificate revocation list (CRL).