SSL/TLS Certificates

October 8, 2026·

Understanding SSL/TLS Certificates can be confusing especially with varying types, different Certificate Authorities, The Certificate Chain, etc. I try to simplity that.

As a general idea:

    flowchart
  Cert["Certificate"] -- contains --> PubKey["Public Key of Website"]
  Cert -- contains --> DN["Domain Name"]
  Cert -- contains --> Signature["CA's Digital Signature"]

Types of SSL Certificates

A certificate can generally be of type single domain, wildcard or multi-domain which is issued by Certificate Authority.

Single Domain Certificate

Applicable only for single domain and not even it’s subdomain
For example: certificate for example.com is only valid for example.com and not blog.example.com or else
However certificate for example.com is valid for all it’s pages such as example.com/learn or example.com/product

Wildcard Certificate

Applicabe for single domain and it’s subdomains too
For example: certificate for example.com is also valid for courses.example.com or *.example.com
If you view the certificate from the browser, you can see the list of all valid subdomains as Subject Alt Names (SANs)

Multi-Domain Certificate

A single certificate sharable by multiple domains, eg: example.com and example-01.com
Can be cost effective solution if HTTPS required for multiple domain owned by a single entity or organization

Types of Certificate Authority (By Function)

A Certificate Authority (CA) is a trusted organization that verifies the identity of websites, servers, users, or devices and issues them a digital certificate however a CA can be of different type:

Domain Validated (DV) CAs

Issues certificate after validating only the ownership of Domain Name for the requested certificate
Since only Domain Name is validated, the process is often very fast
Let’s Encrypt (free, non-profit), sectgo, entrust, etc. provide DV Certificates

Organization Validated (OV) CAs

Issues certificate after validating Domain Name plus details details like: name, legal existence, location, etc.
It takes more time than DV Certificates as more validation requires
digicert, sectgo, entrust, ssl.com, etc. provide OV Certificates (the free one -> Let’s Encrypt doesn’t)

If there is requirement that says: someone owns example-bank.com is not enough, rather Example Bank should own example-bank.com then requesting for Organization Validated Certificate makes sense.

Extended Validated (DV) CAs

It goes one step further from OV and also validates physical plus operational existence, identity of requester, etc.
It may take days to complete validation and finally get the Certificate
digicert, sectgo, entrust, ssl.com, etc. provide DV Certificates

Where Does Self-Signed Certificate Fits?

It fits nowhere because self-signed means signed by you and not by any trusted CA. Cryptographically, there is no additional or less security you get from self-signed certificate but as the certificate is not signed by any trusted CA but by you, certificate issued this way just can’t take part in certificate chain and not recognized by OS or browsers.

This means your use is often limited to test or dev environment where you want HTTPS but don’t want CA’s overhead of getting certificate. Saying that, if your production environment is limited to few users to whom you can distribute the certificate via secure channel and asks them to install in their favorite browser and yes it works. It just works, but it is never a way to do in production. If cost is the problem, Let’s Encrypt is there to serve you.

Important

No matter how or which certificate you get, cryptographically all certificate will have same level of security.

Getting SSL Certificate

SSL Certificate is required when you want to enable HTTPS for your website and is the only way to ensure client’s privacy and server’s integrity and identity. For that you need to request the certificate to Certificate Authority. This request is often called as Certificate Signing Request and the process for this request is roughly the following:

1. Creating and Submitting The Request

This process creates Certificate Signing Request (CSR) file alongwith the private key
This must be performed on the same server where certificate will ultimately be installed because this process also creates private key which should never leave the origin server.
Admins use tools such as openssl or Microsoft IIS, Apache, etc. to generate CSR and private key file
```
    flowchart LR
openssl -- creates --> CSR
openssl -- creates --> privatekey
  
```

What’s On CSR File?

CSR is a digital application form which is used to request SSL/TLS certificate. Therefore, CSR itself is not the certificate but rather the formal request used to get one. Comming back to the OG question -> What’s on CSR File? Well, following:

1. Business Related Information:

Organization (O)’s legally registered name and specific departmant of the organization i.e. Organizational Unit (OU)
Locality (L) or location of the organization and two-letter ISO Country (C) name
Common Name (CN) i.e. your FQDN such as devstuffs.com -> the most important one (for multi-domain certificate, subdomains are specified as SANs)

Important

Make sure the information presented here is accurate, especially Common Name (CN) for DV certificate because it is used by CA to validate organization legitimity.

2. The Public Key

While private key remains securely on the server, public key is embedded in CSR. This is important because after validation when your site is live, browsers and clients use this key to send encrypted data to the server.

CSR is also digitally signed with the private key which confirms that the requester controls both the public key and the private key which can be easily validated by CA because it knows your pubilc key too.

Remember

Private key -> can only sign digital certificates and decrypt the message
Private key -> can only validate digital certificates and encrypt the message

3. Key Type and Length

Key type and length determines the strength of encryption, RSA and ECC are primary key types
RSA is long-standing industry standard where RSA 2048 bits are minimum requirement but generally RSA 3072 is better for enhanced security
ECC is modern alternative because ECC keys provide equivalent security to RSA with much smaller key sizes which improves operational performances

Once CSR file is created and private key is stored securely, the CSR request is submitted to CA.

2. Ownership Validation

After CSR is submitted, CA needs to validate if the information submitted on CSR is indeed correct. Depending on the certificate requirements, CA might perform different level of validation but I will focus on the most common one which is Domain Name validation which is usually perfomed what suits best for CA among the following:

Email Based Validation -> An approval request is sent to your domain based Email
HTTP/HTTPS File Upload -> A validation file is placed on your web server and CA checks it to confirm the ownership
DNS Based Validation -> A unique TXT or CNAME record should be added by you which will be detected by CA to verify administrative control over domain DNS

Important

DNS Based Validation scales as it can be automated more efficiently but it can lead to “DNS debt” enabling gateway for attackers to perform different DNS based attacks if the DNS hygiene is not properly maintained.

3. Review By The Signer (CA)

Reviews all the information in CSR and the result of the previous validation step
A Registration Authority(RA) may be involved as an intermediary to perform some of these checks on the behalf of CA
If everything is validated, CA uses its private key to sign the requested certificate confirming the authenticity
CA might also deny the request if it can’t validate everything it requires to sign the certificate

After all these steps, you finally receive the certificate which can be used to prove the identity for your website.

The Certificate Chain

Browsers and OSes only trust Root CA’s certificate or signature but that doesn’t mean every certificate has to be signed by Root CA’s private key (and that’s not how Root CA do it). The key idea of the certificate chain is that certificate is validated only if it ultimately reaches Root CA in the chain.

Certificate Validation Process

The browser downloads the certificate presented by the server (say example.com). This certificate is digitally signed by the private key of the CA (or an intermediate CA) that issued it.
A Certificate Authority (CA) is a trusted organization that verifies the identity of websites, people, or companies and issues digital certificates to secure online communications.
Browsers/operating systems come with a pre-installed trust store containing trusted root CA certificates. The browser uses the CA’s public key from the certificate chain to verify the digital signatures.
If the certificate is not directly signed by a trusted root CA, the browser follows the certificate chain upward. It finds the intermediate CA that signed the server’s certificate, then checks who signed that intermediate CA, continuing until it reaches a trusted root CA in its trust store. This is called the chain of trust.

example.com certificate
        ↓ signed by
Intermediate CA
        ↓ signed by
Root CA
        ↓ trusted because
Root CA certificate is in browser trust store

Why Intermediate CA?

To sign a certificate, a CA must use its private key. If the Root CA’s private key were used for every certificate, it would need to be accessible on the Root CA server, creating a critical security risk especially with scalability the problem becomes more bigger(and potentially bad actor inside organization may exist too).

If that private key is compromised, an attacker could issue fraudulent certificates trusted by everyone. Since the Root CA is a trust anchor, it cannot be revoked through a higher CA; the compromised root must instead be removed from trust stores and replaced, potentially affecting systems worldwide.

This is why Root CAs are kept highly protected, often offline in highly secure vault(mostly hardware vault), and Intermediate CAs are used for routine certificate issuance.

So:

Root CA signs the Intermediate CA certificate using the root CA’s private key.
The intermediate CA now has a certificate that says, essentially, “this CA is authorized to issue certificates.”
The intermediate CA uses its own private key to sign end-entity certificates.
A browser can validate the chain back to its trusted root.

Important

Remember, The process is still the same! The private key is still involved but instead of Root CA’s private key, its Intermediate CA’s private key now which even if compromised can be revoked immediately (often when known) by Root CA and all the certificates signed by that compromised key are considered invalid.

If an Intermediate CA is compromised, the Root CA can revoke it. Certificates issued by that Intermediate CA must then be replaced, but the Root CA itself remains trusted.

The ultimate duty of Root CA then becomes:

Issuing Certificate for Intermediate CA
Revoking Intermediate CA if compromised

                Root CA
             [private key]
                  │
             signs rarely
                  ▼
           Intermediate CA
          [private key online]
                  │
          signs frequently
                  ▼
        End-entity certificates

Understand How HTTPS Actually Works

a must read

Managing Multiple SSH Keys And Servers

security

References

Certificate Signing Requests -> https://www.digicert.com/blog/csr-certificate
Types of CAs -> https://www.sectigo.com/blog/understanding-the-different-types-of-certificate-authorities
Types of SSL certs -> https://www.cloudflare.com/learning/ssl/types-of-ssl-certificates/

Last updated on October 30, 2026

How HTTPS Works?How Pod Identity Works in EKS?