What are X.509 certificates? Link to heading

A X.509 is the standard certificate format of signed certificate which contains details like the server’s public key, the domain name it’s valid for, who issued it, how long it’s valid etc.

You don’t really need to memorize the structure, but the idea is that every certificate on the internet follows the same blueprint, so browsers know exactly where to look for things like the public key, issuer, and signature. It’s what makes the whole system interoperable.

How does a CSR request looks like? Link to heading

A CSR is basically just a structured blob of data that contains your public key + some identity info, all wrapped up and signed with your private key. In practice, it usually looks like this (PEM format):

Yeah… not exactly human-friendly. That entire middle part is just base64-encoded binary. If you decode it, you’d see structured fields like:

Common Name (your domain, e.g. www.example.com)
Organization, country, etc. (optional, depends on cert type)
Your public key
A signature created using your private key

So the CA doesn’t just get your public key — it also gets proof that you actually own the corresponding private key (because only you could have signed that request).

If you want to see a slightly more expanded view, tools like openssl can decode it and show something like:

Certificate Request:
    Data:
        Subject: C=IN, ST=New Delhi, City=New Delhi, O=Example Ltd, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
    Signature Algorithm: sha256WithRSAEncryption

TLS uses Symmetric or Asymmetric? Link to heading

TLS uses both types of encryption, but at different stages.

It starts with asymmetric encryption. This is where we have been talking about “Chain of Trust” and this is where we use it to verify the server’s identity and safely establish a shared secret between client and server (again, using a pre-computed hash).

Once that’s done, the further server / client communication switches to symmetric encryption for the actual data transfer, because it’s much faster and more efficient.

TLS outside of Browser Link to heading

The certificates issued by Root CA doesn’t only verify website domains… They can also verify domains on other protocols as well.

That’s how we get FTPS, SMTPS, IMAPS. Even most database connection nowadays also send data over the network using TLS (eg. Postgres on 5432 uses encrypted transfer). The underlying mechanism is the same. How Root CAs identify and trust a domain and it’s public key. How your OS verifies the trust and establishes connection “securely”.

What about SSH? Why is it not SHS(ecure)? Link to heading

SSH doesn’t use TLS — it has its own protocol and key exchange mechanisms. But it achieves a similar end: a secure, encrypted channel between two systems. It uses encrypted pipes and request / response is passed through those pipes via tunneling. This mechanism also let’s you forward ports securely by creating a secure SSH Tunnel (created on the application layer in the OSI model)

Info

Remember how whenever you try to connect to a machine via SSH it prompts you something like:

The authenticity of host 'example.com' can't be established.
ECDSA key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no)?

Why do you think it’s asking you for this? 😏

In this case, it is putting the responsibility on “YOU” (instead of verifying with a CA). If you say “yes” (means you trust the public key), your system stores that server’s public key in a file called known_hosts which is why you’re not prompted a second time for the same public key received while establishing that connection.

Umm… VPNs? Link to heading

VPNs also “encrypt your traffic,” but they operate at a completely different layer. Instead of securing a single connection (like browser -> server), a VPN creates a secure “tunnel” at the network layer. Once you’re connected, all your traffic — browser, apps, background services — gets routed through that tunnel.

So it’s not the same for VPNs.

The tunneling VPN uses is not same as SSH

That’s a wrap. Link to heading

With this, I have covered every topic I researched and discovered while learning in-depth about TLS certificates and encryption standards that are followed in the wild. Can officially close this series for good. However, I have one last thing planned tho i.e. to generate (and also setup auto-renewal) TLS certificates for a hosted domain. I mean, I personally wouldn’t be using it anywhere, but there’s this little craving for performing hands-on after acquiring all this knowledge.

So, if you like to follow along, checkout the next post after this in the series. If you have any feedback about my blogs, I am all ears on X. Until then…

Sayo-nara.