Beginners guide on PKI, Certificates, Extensions, CA, CRL and OCSP

Written by - Deepak Prasad

In this article I will try cover some of the key areas related to Certificates so that you get have an overview of Openssl certificates, types, extensions etcs

I have already written multiple articles on OpenSSL, I would recommend you to also check them for more overview on openssl examples:



Public Key Infrastructure (PKI) provides the means to establish trust by binding public keys and identities, thus giving reasonable assurance that we’re communicating securely with who we think we are. PKI is important to using public key cryptography effectively, and is essential to understanding and using the SSL protocol.

Using public key cryptography, we can be sure that only the encrypted data can be decrypted with the corresponding private key. If we combine this with the use of a message digest algorithm to compute a signature, we can be sure that the encrypted data has not been tampered with. What’s missing is some means of ensuring that the party we’re communicating with is actually who they say they are. In other words, trust has not been established. This is where PKI fits in.

Tutorial: Overview on PKI, Certificates, Extensions, CA, CRL and OCSP



  • At the heart of PKI is something called a certificate .
  • In simple terms, a certificate binds a public key with a distinguished name .
  • A distinguished name is simply the name of the person or entity that owns the public key to which it’s bound.
  • A certificate is signed with the issuer’s private key, and it contains almost all of the information necessary to verify its validity. It contains information about the subject, the issuer, and the period for which it is valid. The key component that is missing is the issuer’s certificate. The issuer’s certificate is the key component for verifying the validity of a certificate because it contains the issuer’s public key, which is necessary for verifying the signature on the subject’s certificate.
  • A certificate is signed with the issuer’s private key, and it contains almost all of the information necessary to verify its validity
    Certificates are also created with a serial number embedded in them. The serial number is unique only to the issuer of the certificate. No two certificates issued by the same issuer should ever be assigned the same serial number. The certificate’s serial number is often used to identify a certificate quickly


Certificate Types

Some of the most used certification types are:

  • Wildcard: Certificates are assigned a common name when created, and the common name matches the URL of the site or entity using the certificate.
  • SAN:   A subject alternative name (SAN) certificate is a certificate that can have multiple common names associated with the certificate.
  • Code signing:   A code-signing certificate would be used to digitally sign application code that you create.
  • Self-signed:   A self-signed certificate is used by the root CA. Each entity within the PKI needs a certificate.
  • Root:   When a PKI is created, the first certificate authority installed is known as the root CA.


Certification Authorities

A Certification Authority (CA) is an organization or company that issues certificates
The CA must ensure beyond all reasonable doubt that every certificate it issues contains a public key that was issued by the party that claims to have issued it.

There are two basic types of CAs.

  • A private CA has the responsibility of issuing certificates only for members of its own organization, and is likewise trusted only by members of its own organization.
  • A public CA, such as VeriSign or Thawte, has the responsibility of issuing certificates for any member of the public, and must be trusted by the public


Certificate Hierarchies

A certificate that is issued by a CA can be used to issue and sign another certificate, if the issued certificate is created with the appropriate permissions to do so. In this way, certificates can be chained.
At the root of the chain is the root CA’s certificate. Because it is at the root of the chain and there is no other authority to sign its certificate, the root CA signs its own certificate. Such a certificate is known as a self-signed certificate.


Certificate Extensions

The most widely accepted format for certificates is the X.509 format. There are three versions of the format, known as X.509v1, X.509v2, and X.509v3. The most recent revision of the standard was introduced in 1996, and most, if not all, modern software now supports it. A large number of changes were made between X.509v1 and X.509v3, but perhaps one of the most significant features introduced in the X.509v3 standard is its support of extensions.


Certificate Formats

There are different certificate formats because of the way the information is stored in the certificate. The following identifies common file formats for certificates:

  • DER/CER   Distinguished Encoding Rules (DER) and Canonical Encoding Rules (CER) are binary file formats used to store information in the certificate file. DER-formatted files can have a .der or a .cer file extension.
  • PEM   Privacy-enhanced Electronic Mail (PEM) is an ASCII file format that can have a file extension of .pem, .crt, .cer, or .key. PEM files are very common and start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.
  • PFX/P12   The Personal Information Exchange (PFX) format, also known as the P12 or PKCS#12 format, is a binary file format that is common with Microsoft environments for importing and exporting certificates. PFX formatted files have an extension of .pfx or .p12.
  • P7B   The P7B format, also known as PKCS#7, is another ASCII file format used to store certificate information. If you open the ASCII file, you will see that it begins with the text -----BEGIN PKCS7----- and ends with -----END PKCS7-----. P7B files can have an extension of .p7b or .p7c.


Certificate Revocation Lists

Once a certificate has been issued, it is generally put into production, where it will be distributed to many clients. If an attacker compromises the associated private key, he now has the ability to use the certificate even though it doesn’t belong to him. Assuming the proper owner is aware of the compromise, a new certificate with a new key pair should be obtained and put into use. In this situation there are two certificates for the same entity—both are technically valid, but one should not be trusted. The compromised certificate will eventually expire, but in the meantime, how will the world at large know not to trust it?

The answer lies in something called a certificate revocation list (CRL). A CRL contains a list of all of the revoked certificates a CA has issued that have yet to expire. When a certificate is revoked, the CA declares that the certificate should no longer be trusted.


Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP), formally specified in RFC 2560, is a relatively new addition to PKI. Its primary aim is to address some of the distribution problems that have traditionally plagued CRLs.

Using OCSP, an application makes a connection to an OCSP responder and requests the status of a certificate by passing the certificate’s serial number. The responder replies “good,” “revoked,” or “unknown.” A “good” response indicates that the certificate is valid, so far as the responder knows. This does not necessarily mean that the certificate was ever issued, just that is hasn’t been revoked. A “revoked” response indicates that the certificate has been issued and that it has indeed been revoked. An “unknown” response indicates that the responder doesn’t know anything about the certificate. A typical reason for this response could be that the certificate was issued by a CA that is unknown to the responder.


How TLS Communication Works?

When you SSL-enable a web site, you should understand how the encryption works with the web site. The following are the general steps taken by a client visiting your web site and the web server:

  1. Client Initiates Connection:
    • The client sends a 'ClientHello' message to the server, specifying the highest SSL/TLS version it supports, a list of supported cipher suites, and other SSL/TLS options.
  2. Server Responds:
    • The server responds with a 'ServerHello' message, choosing the SSL/TLS version and cipher suite from the options provided by the client (usually the highest common version and most secure cipher suite).
    • The server sends its digital certificate, which contains the server's public key.
  3. Certificate Validation:
    • The client validates the server’s certificate against a list of trusted Certificate Authorities (CAs) to ensure its authenticity. This includes checking the certificate's expiration date, its signature, and whether it has been revoked.
  4. Pre-Master Secret and Symmetric Key Generation:
    • The client generates a pre-master secret using strong random numbers and encrypts it with the server's public key, then sends it to the server.
    • Both the client and server independently use this pre-master secret to generate the same symmetric session key.
  5. Encryption of Communication:
    • The client sends a 'Finished' message to the server, encrypted with the symmetric session key.
    • The server decrypts this message, ensuring that the session key works, and then sends an encrypted 'Finished' message back to the client.
    • From this point, all data exchanged between the client and server is encrypted using the symmetric session key.
  6. Session Key Usage:
    • The symmetric key (session key) is used for the duration of the session to encrypt and decrypt data transmitted between the client and server.
  7. Session Resumption (Optional):
    • To save time on subsequent connections, SSL/TLS can use session identifiers or session tickets to resume a previously established session without performing the full handshake again.


How mTLS Communication works?

mTLS, or Mutual TLS, is an extension of TLS (Transport Layer Security) where both the client and the server authenticate each other. This adds an extra layer of security by ensuring both parties in the communication are verified. Here's how the mTLS process differs from the standard TLS process:

  1. Initial Connection:
    • Similar to TLS, the client initiates the connection to the server using a 'ClientHello' message.
  2. Server Response and Certificate Request:
    • The server responds with a 'ServerHello' message, choosing the SSL/TLS version and cipher suite.
    • The server sends its digital certificate to the client.
    • Additionally, the server requests a certificate from the client, indicating that client authentication is required.
  3. Client Certificate and Validation:
    • The client sends its digital certificate to the server.
    • The server validates the client's certificate, similar to how the client validates the server’s certificate in a standard TLS handshake. This includes checking the certificate's expiration date, its signature, and whether it has been revoked.
  4. Pre-Master Secret and Symmetric Key Generation:
    • The process of generating a pre-master secret and symmetric session key is the same as in TLS.
  5. Encryption of Communication:
    • The client and server exchange 'Finished' messages, encrypted with the symmetric session key.
    • All subsequent data exchanged in the session is encrypted using this session key.
  6. Bidirectional Authentication:
    • In mTLS, both the client and the server are authenticated to each other, as opposed to standard TLS where only the server is authenticated to the client.
  7. Session Resumption (Optional):
    • mTLS also supports session resumption for faster subsequent connections, similar to TLS.

The key difference in mTLS compared to standard TLS is the mutual authentication requirement. In mTLS, both the client and the server must present and validate digital certificates.

Network Security with OpenSSL
CompTIA Security+ Certification Guide

Deepak Prasad

He is the founder of GoLinuxCloud and brings over a decade of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels in various domains, from development to DevOps, Networking, and Security, ensuring robust and efficient solutions for diverse projects. You can reach out to him on his LinkedIn profile or join on Facebook page.

Can't find what you're searching for? Let us assist you.

Enter your query below, and we'll provide instant results tailored to your needs.

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can send mail to

Thank You for your support!!

2 thoughts on “Beginners guide on PKI, Certificates, Extensions, CA, CRL and OCSP”

Leave a Comment