In the previous blog, we saw how the TLS handshake establishes an encrypted connection between a client and a server.

But there is an important problem hiding inside that process.

Suppose I visit:

https://bikashshaw.in

The server sends me a public key that can be used as part of establishing secure communication.

But how do I know that this public key actually belongs to bikashshaw.in?

An attacker could theoretically sit between me and the real server and say:

Hey, I am bikashshaw.in.
Here is my public key.

If the browser blindly trusted every public key it received, encryption alone would not solve the problem.

We therefore need a way to authenticate the server.

That is the job of a TLS certificate.

What Is a TLS Certificate?

A TLS certificate is a digitally signed document that binds an identity, usually a domain name, to a public key.

It tells the client something like:

This public key belongs to bikashshaw.in,
and a trusted Certificate Authority has verified it.

A TLS certificate contains information such as:

• Domain names the certificate is valid for

• Server's public key

• Certificate issuer

• Validity period

• Serial number

• Signature algorithm

• Extensions

• Digital signature from the issuer

The certificate is sent during the TLS handshake so that the client can authenticate the server before trusting the secure connection.

Most certificates used on the web follow the X.509 certificate format.

What Is an X.509 Certificate?

X.509 defines the structure used for public-key certificates.

At a high level, an X.509 certificate looks like this:

X.509 Certificate
│
├── TBSCertificate
│
├── Signature Algorithm
│
└── Signature

The most important part is the:

TBSCertificate

where TBS means:

To Be Signed

This contains most of the actual certificate information.

The Certificate Authority takes this data and digitally signs it.

Let's look at what is inside.

Inside the TBSCertificate

Version

This identifies the version of the X.509 certificate format.

Modern TLS certificates generally use:

X.509 Version 3

Version 3 supports extensions, which are heavily used by modern certificates.

Serial Number

Every certificate gets a serial number assigned by the issuer.

For example:

Serial Number:
03:A7:91:42:...

The serial number is unique for certificates issued by that particular CA.

It is also useful when certificates need to be revoked.

Issuer

The issuer tells us which Certificate Authority issued the certificate.

For example:

Issuer:
Let's Encrypt

or more specifically, an intermediate CA operated by Let's Encrypt.

This becomes important when we build the chain of trust later.

Validity Period

Certificates are not valid forever.

They contain two timestamps:

Not Before
Not After

For example:

Not Before:  Sep 1, 2026
Not After:   Nov 30, 2026

The browser checks that the current time lies inside this period.

If the certificate is expired or not yet valid, certificate validation fails.

Subject

Historically, the Subject field described the identity the certificate represented.

It may contain values such as:

Organization
Country
Common Name

Older certificates often placed the domain inside the:

Common Name (CN)

field.

However, modern browsers do not rely on the Common Name for hostname verification.

Instead, domain names are placed inside an extension called:

Subject Alternative Name, or SAN.

Subject Alternative Name

SAN is actually one of the most important fields in a modern TLS certificate.

It contains the domain names for which the certificate is valid.

For example:

Subject Alternative Name:

DNS:bikashshaw.in
DNS:www.bikashshaw.in

When your browser visits:

https://bikashshaw.in

it checks whether bikashshaw.in appears in the certificate's SAN list.

A certificate may also contain wildcard domains:

*.example.com

which could match:

api.example.com
app.example.com
dashboard.example.com

So the certificate is not simply saying:

Here is a public key.

It is saying:

This public key is authorized for these identities.

Subject Public Key Info

Another important field is:

Subject Public Key Info

or:

SubjectPublicKeyInfo

This contains:

Public Key Algorithm
+
Server Public Key

For example, the public key may use:

RSA

or:

ECDSA

The corresponding private key remains secret on the server.

The certificate contains only the public key.

Conceptually:

Server

Private Key
    ↓
SECRET
Never sent to client


Certificate

Public Key
    ↓
Sent to clients

This distinction is extremely important.

Anyone can see the public key.

Only the legitimate server should possess the corresponding private key.

Certificate Extensions

X.509 Version 3 certificates support extensions.

Some important extensions include:

Subject Alternative Name
Basic Constraints
Key Usage
Extended Key Usage
Authority Key Identifier
Subject Key Identifier

For example, Basic Constraints helps distinguish a CA certificate from a normal server certificate.

A CA certificate may contain:

CA = TRUE

while an ordinary server certificate normally has:

CA = FALSE

This prevents a normal website certificate from being treated as a Certificate Authority capable of issuing other certificates.

Key Usage and Extended Key Usage further restrict what the certificate's key can be used for.

For example:

TLS Web Server Authentication

The Complete X.509 Certificate

Once the TBSCertificate is created, the issuer signs it.

Conceptually:

TBSCertificate
      +
Signature Algorithm
      +
Certificate Signature
      =
X.509 Certificate

The certificate therefore contains both the data and cryptographic proof that an issuer approved that data.

The structure can roughly be imagined as:

Certificate
│
├── TBSCertificate
│   │
│   ├── Version
│   ├── Serial Number
│   ├── Issuer
│   ├── Validity
│   ├── Subject
│   ├── Subject Public Key Info
│   └── Extensions
│
├── Signature Algorithm
│
└── Signature Value

How Is a TLS Certificate Created?

Suppose I want a certificate for:

bikashshaw.in

The process starts on my server.

Step 1: Generate a Key Pair

First, the server creates a public/private key pair.

Private Key
     ↓
Kept secret on server


Public Key
     ↓
Can be shared

The private key must never be sent to the Certificate Authority.

Only the public key needs to become part of the certificate.

Step 2: Create a CSR

Next, the server creates a:

Certificate Signing Request, or CSR.

The CSR contains information such as:

Public Key
Requested domain information
Cryptographic algorithm information

The CSR is also normally signed using the server's private key.

This proves that whoever created the CSR actually possesses the private key corresponding to the included public key.

Conceptually:

Public Key
Domain Information
       ↓
      CSR
       ↓
Signed using Server Private Key

The CSR is then sent to the Certificate Authority.

Step 3: Certificate Authority Validates the Request

The CA does not immediately issue a certificate just because someone asks for one.

It first needs to verify that the requester is authorized to obtain a certificate for the domain.

For normal web certificates, this commonly involves proving control over:

bikashshaw.in

Methods can include:

DNS challenge
HTTP challenge
TLS challenge

For example, the CA might ask the domain owner to create a specific DNS record.

If the correct record appears, the CA gains evidence that the requester controls the domain.

Step 4: CA Creates the Certificate

Once validation succeeds, the CA constructs the certificate.

The CA fills the TBSCertificate with information such as:

Serial Number
Issuer
Validity
Subject
Server Public Key
SAN
Extensions

Conceptually:

TBSCertificate

{
    Serial Number
    Issuer
    Validity
    Subject
    Public Key
    SAN
    Extensions
}

Step 5: Encode the TBSCertificate

X.509 certificates are formally described using:

ASN.1

ASN.1 defines the structure of the data.

For certificates, that structure is typically encoded into bytes using:

DER

So we can think of it as:

ASN.1
   ↓
Defines structure

DER
   ↓
Encodes that structure into bytes

DER is particularly useful here because digital signatures require both sides to agree on the exact bytes being signed.

Step 6: CA Signs the Certificate

Now comes the critical step.

The CA takes the encoded TBSCertificate and creates a digital signature using the CA's private key.

A simplified mental model is:

TBSCertificate
      ↓
     Hash
      ↓
Certificate Digest
      ↓
Signed using CA Private Key
      ↓
Certificate Signature

The exact operation depends on the signature algorithm, such as RSA or ECDSA, but the main concept remains the same.

Only the CA possesses its private key.

So if a signature can later be successfully verified using the CA's public key, we gain cryptographic evidence that the CA created the signature.

Step 7: Certificate Is Installed on the Server

The final certificate contains:

TBSCertificate
+
Signature Algorithm
+
CA Signature

The server normally stores:

Server Private Key

Server Certificate

Intermediate CA Certificate(s)

The private key remains secret.

The certificates can be sent to clients during TLS handshakes.

DER vs PEM

Certificates are often stored in files such as:

certificate.der
certificate.crt
certificate.pem

DER is the binary encoding of the certificate.

PEM is usually a Base64 representation of DER surrounded by text markers.

For example:

-----BEGIN CERTIFICATE-----
MIIF...
...
-----END CERTIFICATE-----

So PEM is not a different kind of certificate.

It is mostly a convenient textual representation of DER-encoded certificate data.

What Happens When We Visit a Website?

Now suppose a user visits:

https://bikashshaw.in

The TLS handshake begins.

At one stage, the server sends its certificate chain.

Conceptually:

Browser
   |
   | ClientHello
   |
   ↓

Server
   |
   | ServerHello
   | Certificate
   | ...
   ↓

The browser now has to determine:

Can I trust this certificate?

This is where certificate verification begins.

The Server Sends a Certificate Chain

The server typically sends:

Leaf Certificate
        +
Intermediate Certificate(s)

For example:

bikashshaw.in Certificate
          ↓
Let's Encrypt Intermediate CA

The server usually does not send the root certificate.

Why?

Because sending the root certificate would not establish trust.

The browser needs to already trust that root.

The trusted root certificate exists locally inside the browser or operating system's trust store.

Chain of Trust

Suppose the certificate hierarchy looks like this:

Root CA
   ↓
Intermediate CA
   ↓
bikashshaw.in

Each certificate is signed by the certificate above it.

So:

Root CA Private Key
        ↓ signs

Intermediate Certificate
        ↓

Intermediate CA Private Key
        ↓ signs

bikashshaw.in Certificate

The browser verifies this chain from the website certificate toward a trusted root.

Step 1: Verify the Website Certificate

The bikashshaw.in certificate says something like:

Issuer:
Intermediate CA

The browser obtains the Intermediate CA's public key from the intermediate certificate.

It then uses that public key to verify the digital signature on the website certificate.

Conceptually:

bikashshaw.in Certificate

TBSCertificate
        ↓
      Hash
        ↓
   Calculated Hash

Meanwhile:

Certificate Signature
        +
Intermediate CA Public Key
        ↓
Signature Verification

If the signature is valid, the browser knows:

The holder of the Intermediate CA private key
signed this certificate.

Assuming that key has not been compromised, the signature cannot practically be forged.

Step 2: Verify the Intermediate Certificate

But we have only moved the trust problem one level upward.

Why should we trust the Intermediate CA?

The intermediate certificate itself has an issuer.

For example:

Issuer:
Root CA

The browser now verifies the intermediate certificate using the Root CA's public key.

Intermediate Certificate
        ↓
Signed by Root CA

So the chain becomes:

bikashshaw.in
       ↓ verified using
Intermediate Public Key

Intermediate CA
       ↓ verified using
Root Public Key

Root CA

Step 3: Trust the Root Certificate

Now we reach the root certificate.

A root certificate is generally self-signed.

Conceptually:

Root Certificate
      ↓
Signed using
Root Private Key

and the signature can be verified using:

Root Public Key

But this raises an interesting question.

If the root signs itself, how does that prove we should trust it?

It doesn't.

This is the key idea.

Root CA trust is not established by its self-signature.

The browser trusts the root because that root certificate was already placed in a trusted certificate store.

Operating systems and browsers maintain collections of trusted root Certificate Authorities.

For example:

Trust Store

├── Root CA A
├── Root CA B
├── Root CA C
└── Root CA D

The trust anchor comes from this local configuration, not from the network.

This gives us the complete chain:

              Already Trusted
                    ↓
                 Root CA
                    ↓
                  signs
                    ↓
             Intermediate CA
                    ↓
                  signs
                    ↓
              bikashshaw.in

This is called the:

Chain of Trust

Why Doesn't the Server Send the Root Certificate?

A server could technically include a root certificate in the certificates it sends, but clients normally do not need it and should not trust it merely because the server supplied it.

Imagine an attacker sending:

Fake Website Certificate
        ↓
Fake Intermediate CA
        ↓
Fake Root CA

and saying:

Here is my root certificate.
Please trust it.

That would make certificates useless.

The browser only trusts root certificates that already exist in its trusted root store.

So the usual server-provided chain looks like:

Server sends:

Leaf Certificate
Intermediate Certificate
Intermediate Certificate

while the browser completes it using:

Trusted Root Certificate

from its own trust store.

Certificate Verification Is More Than Checking the Signature

Successfully verifying the digital signatures is only one part of certificate validation.

The browser also checks several other conditions.

For example:

Is the certificate currently valid?

Does the requested hostname appear in SAN?

Is the certificate allowed to authenticate a TLS server?

Are the Basic Constraints valid?

Does the chain lead to a trusted root?

Has a certificate been revoked?

Are the cryptographic algorithms acceptable?

Suppose the certificate is perfectly signed but contains:

SAN:
example.com

and the user visits:

bikashshaw.in

The browser must reject it.

Similarly, if:

Not After:
September 1, 2026

and the current date is later than that, the certificate is expired even if all signatures are valid.

So certificate validation can roughly be thought of as:

Signature Valid
       +
Hostname Valid
       +
Validity Period Valid
       +
Usage Allowed
       +
Certificate Chain Valid
       +
Trusted Root
       =
Certificate Accepted

What Does the Certificate Actually Prove?

There is another subtle point worth understanding.

A certificate does not usually say:

This server belongs to the person named Bikash.

For a normal domain-validated certificate, it primarily proves something closer to:

A trusted Certificate Authority verified that
the requester controlled bikashshaw.in,
and this public key was certified for that domain.

The server then proves possession of the corresponding private key during the TLS handshake.

So authentication requires both:

Certificate
      +
Corresponding Private Key

Stealing only the public certificate file is not enough to impersonate the server.

Putting the Whole Certificate Issuance Flow Together

The complete flow looks like this:

Server

Generate Key Pair
      ↓

Private Key ────────────────→ Keep Secret
      |
Public Key
      ↓

Create CSR
      ↓

Send CSR to CA
      ↓

CA verifies domain ownership
      ↓

CA creates TBSCertificate
      ↓

ASN.1 structure
      ↓

DER encoding
      ↓

CA signs TBSCertificate
using CA Private Key
      ↓

X.509 Certificate
      ↓

Install certificate
on server

And the Verification Flow

Later, when a user visits the website:

Browser
   |
   | HTTPS request
   ↓

TLS Handshake
   |
   ↓

Server sends:

bikashshaw.in Certificate
Intermediate CA Certificate

The browser then builds the chain:

bikashshaw.in
      ↓
Intermediate CA
      ↓
Root CA
      ↓
Local Trust Store

It verifies each certificate signature using the issuer's public key.

Finally, it checks:

Hostname
Validity
Key Usage
Certificate Constraints
Trusted Root
Other security rules

If everything is valid:

Certificate Trusted
        ↓
Server Authenticated
        ↓
TLS Handshake Continues

Final Mental Model

The easiest way to think about TLS certificates is:

Certificate Authority says:

"I verified that this public key
is authorized for this identity."

and digitally signs that statement.

The browser then asks:

Who signed this certificate?
        ↓
Intermediate CA

Who signed that?
        ↓
Root CA

Do I already trust this Root CA?
        ↓
Yes, it exists in my trust store.

That creates:

Browser Trust Store
        ↓
      Root CA
        ↓
 Intermediate CA
        ↓
 Website Certificate
        ↓
    Server Public Key

The certificate does not create encryption by itself.

Its primary job is to establish trust in the identity behind a public key.

That is what prevents an attacker from simply generating their own key pair and claiming:

I am bikashshaw.in.
Trust me.

TLS encryption becomes useful only when the client can be confident that it is encrypting its communication with the correct server.

That is exactly what X.509 certificates and the chain of trust provide.

• It is used to to establish the identity of a server.

• Mainly used to share the public key

• Issued and digitally signed by a Certified Authority

• Contains the information such as domain, public key, issuer, validity period and CA signature.

• Used during TLS handshake to authenticate the server

All the certificates being is used on the internet are most of them are X.509 Certificates

• Version: Which version of X509 certificate it is

• Serial No: serial number of the certificate unique to it

• Issuer: which CA is issuing this cert

• Validity: not before and not after

• SUbject: For which server and domain this is issued

• Subject Public info: Stores the public key and the algo used to create that

• Extension: it contains SAN and many more which is not so important

This is all the field is called To be signed Certificate (TBSCertificate)

After signing and mentioning the signature algorithm(algo used by the issuer to create the certificate), finally a TLS certificate becomes ready so TBSCertificate + Sign Algo + Cert Sign = X509 certificat