# Computer Networks #15: TLS Certificate

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:

```text
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`](http://bikashshaw.in)?

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

```text
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:

```text
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:

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

The most important part is the:

```text
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:

```text
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:

```text
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:

```text
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:

```text
Not Before
Not After
```

For example:

```text
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:

```text
Organization
Country
Common Name
```

Older certificates often placed the domain inside the:

```text
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:

```text
Subject Alternative Name:

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

When your browser visits:

```text
https://bikashshaw.in
```

it checks whether [`bikashshaw.in`](http://bikashshaw.in) appears in the certificate's SAN list.

A certificate may also contain wildcard domains:

```text
*.example.com
```

which could match:

```text
api.example.com
app.example.com
dashboard.example.com
```

So the certificate is not simply saying:

```text
Here is a public key.
```

It is saying:

```text
This public key is authorized for these identities.
```

# Subject Public Key Info

Another important field is:

```text
Subject Public Key Info
```

or:

```text
SubjectPublicKeyInfo
```

This contains:

```text
Public Key Algorithm
+
Server Public Key
```

For example, the public key may use:

```text
RSA
```

or:

```text
ECDSA
```

The corresponding private key remains secret on the server.

The certificate contains only the **public key**.

Conceptually:

```text
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:

```text
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:

```text
CA = TRUE
```

while an ordinary server certificate normally has:

```text
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:

```text
TLS Web Server Authentication
```

# The Complete X.509 Certificate

Once the TBSCertificate is created, the issuer signs it.

Conceptually:

```text
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:

```text
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:

```text
bikashshaw.in
```

The process starts on my server.

## Step 1: Generate a Key Pair

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

```text
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:

```text
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:

```text
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:

```text
bikashshaw.in
```

Methods can include:

```text
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:

```text
Serial Number
Issuer
Validity
Subject
Server Public Key
SAN
Extensions
```

Conceptually:

```text
TBSCertificate

{
    Serial Number
    Issuer
    Validity
    Subject
    Public Key
    SAN
    Extensions
}
```

# Step 5: Encode the TBSCertificate

X.509 certificates are formally described using:

```text
ASN.1
```

ASN.1 defines the structure of the data.

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

```text
DER
```

So we can think of it as:

```text
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:

```text
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:

```text
TBSCertificate
+
Signature Algorithm
+
CA Signature
```

The server normally stores:

```text
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:

```text
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:

```text
-----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:

```text
https://bikashshaw.in
```

The TLS handshake begins.

At one stage, the server sends its certificate chain.

Conceptually:

```text
Browser
   |
   | ClientHello
   |
   ↓

Server
   |
   | ServerHello
   | Certificate
   | ...
   ↓
```

The browser now has to determine:

```text
Can I trust this certificate?
```

This is where certificate verification begins.

# The Server Sends a Certificate Chain

The server typically sends:

```text
Leaf Certificate
        +
Intermediate Certificate(s)
```

For example:

```text
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:

```text
Root CA
   ↓
Intermediate CA
   ↓
bikashshaw.in
```

Each certificate is signed by the certificate above it.

So:

```text
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`](http://bikashshaw.in) certificate says something like:

```text
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:

```text
bikashshaw.in Certificate

TBSCertificate
        ↓
      Hash
        ↓
   Calculated Hash
```

Meanwhile:

```text
Certificate Signature
        +
Intermediate CA Public Key
        ↓
Signature Verification
```

If the signature is valid, the browser knows:

```text
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:

```text
Issuer:
Root CA
```

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

```text
Intermediate Certificate
        ↓
Signed by Root CA
```

So the chain becomes:

```text
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:

```text
Root Certificate
      ↓
Signed using
Root Private Key
```

and the signature can be verified using:

```text
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:

```text
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:

```text
              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:

```text
Fake Website Certificate
        ↓
Fake Intermediate CA
        ↓
Fake Root CA
```

and saying:

```text
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:

```text
Server sends:

Leaf Certificate
Intermediate Certificate
Intermediate Certificate
```

while the browser completes it using:

```text
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:

```text
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:

```text
SAN:
example.com
```

and the user visits:

```text
bikashshaw.in
```

The browser must reject it.

Similarly, if:

```text
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:

```text
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:

```text
This server belongs to the person named Bikash.
```

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

```text
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:

```text
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:

```text
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:

```text
Browser
   |
   | HTTPS request
   ↓

TLS Handshake
   |
   ↓

Server sends:

bikashshaw.in Certificate
Intermediate CA Certificate
```

The browser then builds the chain:

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

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

Finally, it checks:

```text
Hostname
Validity
Key Usage
Certificate Constraints
Trusted Root
Other security rules
```

If everything is valid:

```text
Certificate Trusted
        ↓
Server Authenticated
        ↓
TLS Handshake Continues
```

# Final Mental Model

The easiest way to think about TLS certificates is:

```text
Certificate Authority says:

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

and digitally signs that statement.

The browser then asks:

```text
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:

```text
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:

```text
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