Public key infraestructure — PKI

How does asymmetric encryption work?

When using asymmetric encryption we make use of two sets of key pairs, a public (which is shared) and a private (which is not shared). The Public key is used to encrypt the message to a receiver and the receiver then can decrypt the message using their own private key. When we encrypt a message it is called ciphertext. Do not worry about what occurs from behind, it is all about mathematics, in which those two keys are able to solve the same puzzle!

Figure #1. Asymmetric Encryption

Digital Certificates

The digital certificates help to guarantee authentication, as well as confidentiality since it associates a public key with a specific entity. It is issued by a CA (certificate authority), more of this later on this post.

Figure #2. Inside a container

Types of certificates

  • Self-signed certificate: These certificates won’t be trusted by the browsers of external users, but internal systems may be configured to trust the internal CA, saving the expense of obtaining certificates from a third-party CA.
  • Root certificate: the top-level certificate for their entire PKI.
  • Personal certificate: Identifies a person and includes a digitally signed version of the person’s name, organization, and public key

Certificate formats

  • Distinguished encoding rules (DER)
  • Privacy enhanced mail (PEM)
  • Personal information exchange (PFX): Commonly in windows systems
  • .cer

Certificate of Authority (CA)

The CA manages certificates from issuing, revoking, and distribution. 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, and once confirmed the public key is stored in a directory that is available to anyone that wants to verify your certificate. Some examples of CA are VeriSign, DigiCert. This is also known as the Root CA.

  • Offline CA: Certificate authorities must carefully protect their own private keys to preserve their trust relationships. To do this, they often use an offline CA to protect their root certificate, this offline CA is disconnected from networks and powered down until it is needed. The offline CA uses the root certificate to create subordinate intermediate CAs that serves as the online CAs used to issue certificates on a routine basis.

Intermediate CA

Transfer trust between different CAs. The purpose of creating and using intermediate Cas is primarily for security. They can register their own certificates, if this one is vulnerable it will only affect the certificate belonging to him. So the root CA will remain secure since it is usually turned off after the Intermediate CA servers are live!

Registration authority (RA)

Here is where new certificates are created, but not where they are signed. It verifies the information, payment, and all the data to generate a valid certificate. You can also send to them your own created public key instead of relying on the third-party CA to create both keys. It is important that only the Registrant can revoke the certificate, if they do no longer work for the company, you must revoke those certs and create a new one. There are some specific validations that can be done when deciding if there is a certificate that can be issued or not:

  • Domain validation (DV): Simply verifies that the certificate subject has control of the domain name.
  • Extended validation (EV): A higher level of assurance and the CA takes steps to verify that the certificate owner is a legitimate business before issuing the certificate.

Validation Authority (VA)

The VA provides validation of PKI certificates. If we are going to visit a website, the browser will look to this VA and check for the certificate validation services that can include access to Certificate Revocation Lists (CRL), Online Certificate Status Protocol (OCSP), and CA chain certificate downloads.

Certificate revocation list (CRL)

It is the place where each CA put a list of revoked certificates this should be posted in a public directory. There are different reasons in which a certificate might be revoked, for example:

  • Certificate expiration: The expiration date was met
  • Certificate revocation: which is permanent, due to a compromised private key, company name changes, the key owner does no longer works for the company, etc.
  • Suspended certificates: To put the certificate on “hold”

Online Certificate Status Protocol (OCSP)

Checks the state of the certificate, it asks (the browser) and the OCSP responder will reply if it is valid or invalid. For example, it will check if the certificate is not in the CRL.

The Certificate request and validation process

It might be hard to explain this without a video, but I’ve enumerated each of the steps.

Recovery Agent (We lost the key, what can we do now?)

The person who created the certificate needs to access the key recovery server, normally it is an in-house CA implementation. And you will be requested for some Key Recovery Information (KRI) such as:

  • The proof that the request is from an authorized agent
  • Name of the key owner
  • Time key was created
  • Issuing CA server

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josué Carvajal

Josué Carvajal

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH