Understanding SSL Certificates, CSR, and the Certificate Chain

If you've ever set up HTTPS on a website, you've dealt with SSL certificates — but the whole process can feel confusing the first time. What is a CSR? Why do you need to create one? What's the difference between a root certificate, an intermediate, and the one you actually install on your server? This guide explains all of it in plain English, from start to finish.

1. What is SSL / TLS?

SSL stands for Secure Sockets Layer. TLS stands for Transport Layer Security. They are cryptographic protocols that create an encrypted connection between a web browser (or any client) and a server.

In everyday language: SSL/TLS is what makes the padlock icon appear in your browser and what turns http:// into https://. It protects the data flowing between the user and the server so that nobody in the middle can read or tamper with it.

SSL was the original protocol, but it had security weaknesses and has been deprecated. TLS is the modern successor — TLS 1.2 and TLS 1.3 are what everything uses today. Despite this, most people still say "SSL" because the name stuck. When someone says "SSL certificate," they almost always mean a TLS certificate.

2. What does an SSL certificate actually do?

An SSL certificate does two important things:

a) Encryption

It enables an encrypted connection. When your browser connects to a server over HTTPS, the two sides perform what is called a TLS handshake. During this handshake, they agree on encryption keys. After the handshake, all data flows encrypted — your passwords, form data, payment details, everything. Even if someone intercepts the traffic, they cannot read it.

b) Identity verification

The certificate also proves that the server you're connecting to is actually who it claims to be. The certificate contains the domain name it was issued for (for example, example.com) and it is digitally signed by a Certificate Authority (CA) that your browser already trusts. This prevents attackers from setting up a fake server pretending to be your bank.

3. What is a CSR (Certificate Signing Request)?

A CSR (Certificate Signing Request) is a block of encoded text that you generate on your server. It contains two things:

• Your public key — a mathematical key that is safe to share publicly.
• Identity information — details about your domain and organisation that will appear in the final certificate.

A CSR looks like this:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgx
... (many lines of base64-encoded data) ...
HkKVY9rKKHqeZ9Kk9XsGJn3V3t==
-----END CERTIFICATE REQUEST-----

Inside this encoded data, you'll typically find these fields:

• CN (Common Name) — the domain name, e.g. example.com
• O (Organization) — your company name
• OU (Organizational Unit) — department, e.g. IT Department
• L (Locality / City) — your city
• ST (State / Province) — your state or region
• C (Country) — two-letter country code, e.g. US, IN, GB
• emailAddress — contact email (optional)

4. Why do you need to create a CSR?

The CSR is the starting point of the whole certificate process. Here's why it exists and why it matters:

The private key never leaves your server

When you generate a CSR, your server creates a key pair — a private key and a public key. The private key stays on your server and is never shared with anyone, including the Certificate Authority. The CSR only contains the public key.

This is fundamental to how asymmetric cryptography works. Data encrypted with the public key can only be decrypted with the matching private key. This means only your server can decrypt the traffic, even though the public key was shared with the world.

The CA verifies and signs the request

You submit the CSR to a Certificate Authority (CA) — a trusted organisation like Let's Encrypt, DigiCert, Sectigo, or GlobalSign. The CA verifies that you actually control the domain in the CSR (through DNS records, file uploads, or email). Once verified, they sign the CSR with their own private key and issue you a certificate.

The certificate binds your domain to your public key

The issued certificate is basically a signed statement from the CA saying: "We have verified that the owner of this domain controls this public key." When a browser connects to your site, it can verify that signature, trust the certificate, and establish an encrypted session using your public key.

5. How to create a CSR

The most common way to generate a CSR is using OpenSSL on the command line. Here's the standard command:

# Generate a new private key and CSR in one command
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

This creates two files: yourdomain.key (your private key — keep this safe and secret) and yourdomain.csr (the signing request — this is what you submit to the CA).

To specify all subject fields in one line without interactive prompts:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key \
  -out yourdomain.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=My Company/CN=example.com"

6. The certificate chain: Root, Intermediate, and Server certificates

When a CA issues your certificate, it doesn't sign it directly with the most trusted root certificate. Instead, there is a chain of trust — a hierarchy of certificates — and understanding this chain is important for correctly installing certificates on your server.

7. Root Certificate

A Root Certificate is the top of the certificate hierarchy. It is a self-signed certificate — meaning the Certificate Authority signed it with its own private key. There is no higher authority above it.

Root certificates are distributed by the CA to browser and operating system vendors (Google, Mozilla, Microsoft, Apple). They are pre-installed in your browser, your operating system, and your phone. The list of trusted root certificates your device has is called the Root Store.

Because root certificates are so fundamentally trusted, they are kept extremely secure — often stored in hardware security modules (HSMs) in offline, physically protected facilities. They are almost never used directly to sign customer certificates. Instead, they sign intermediate certificates.

What a root certificate looks like decoded:

• Subject = Issuer — the same organisation issued and signed it (self-signed)
• Basic Constraints: CA = TRUE — it is authorised to issue other certificates
• Long validity period — typically 20+ years
• Key Usage: Certificate Signing

8. Intermediate Certificate

An Intermediate Certificate (also called a Sub-CA or Issuing CA) is signed by the root CA and sits in the middle of the chain. This is the certificate that the CA actually uses to sign your server certificate.

Why not just use the root directly?

Two reasons: security and flexibility.

If a root certificate were ever compromised, every certificate it had ever signed would need to be revoked — a catastrophic event. By using an intermediate, the root stays safely offline. If an intermediate gets compromised, the CA revokes just that intermediate and issues a new one. The root continues to be trusted.

It also allows CAs to operate across multiple regions, products, or business units with separate intermediate CAs, all tracing back to the same trusted root.

What you need to do with intermediate certificates

When you install an SSL certificate on your server, you usually need to install both your server certificate and the intermediate certificate(s) together. This is called a certificate bundle or CA bundle.

If you only install your server certificate without the intermediates, browsers may show a "certificate not trusted" error — because they can't build the chain from your cert back to a trusted root. The intermediate is the missing link.

9. Server Certificate (End-Entity Certificate)

The server certificate (also called the end-entity certificate or leaf certificate) is the one issued specifically for your domain. This is what you get back from the CA after submitting your CSR.

It contains:

• Your domain name in the Common Name (CN) and/or Subject Alternative Names (SANs)
• Your public key (from the CSR)
• Validity period — the dates between which it is valid (typically 1 year or 90 days for Let's Encrypt)
• Issuer information — which intermediate CA signed it
• Digital signature from the intermediate CA

What a server certificate does NOT contain

The server certificate does not contain your private key. It never will. The private key stays permanently on your server. The certificate only contains the public key.

10. How trust flows through the chain

When your browser connects to an HTTPS site, it performs chain validation:

If any link in this chain is broken — expired cert, missing intermediate, revoked cert, domain mismatch — the browser shows a security warning and refuses the connection.

11. Certificate file formats (.pem, .crt, .der, .p7b)

SSL certificates come in several file formats. They all contain the same data but encoded differently.

• .pem — The most common format. Base64-encoded, plain text, starts with -----BEGIN CERTIFICATE-----. Used by most Linux/Apache/Nginx servers. A PEM file can contain a full certificate chain (multiple certificates stacked).
• .crt / .cer — Usually PEM format with a different file extension. Sometimes DER (binary). Apache and Nginx use .crt. Windows systems often use .cer.
• .der — Binary format (not human-readable). The same data as PEM but in raw binary. Used more often in Java environments. You cannot open it in a text editor.
• .p7b / .p7c — PKCS#7 format. Can contain a certificate chain without the private key. Common in Windows and Java. Contains one or more certificates in a bundle.
• .pfx / .p12 — PKCS#12 format. Contains both the certificate and the private key. Password protected. Used for Windows IIS, Azure, and for exporting/importing full certificate+key pairs. Never share a .pfx file — it contains your private key.
• .csr — Not actually a certificate — it's the Certificate Signing Request you generate before getting a cert. PEM format, starts with -----BEGIN CERTIFICATE REQUEST-----.

12. Certificate validity and expiry

All SSL certificates have a validity period — a "Not Before" and "Not After" date. The certificate is only trusted within this window. An expired certificate triggers a browser warning just as severe as a self-signed or untrusted one.

Maximum validity periods

• As of 2020, publicly trusted certificates cannot have a validity period of more than 398 days (roughly 13 months).
• Let's Encrypt certificates are valid for 90 days and are designed to be auto-renewed.
• Root certificates can have much longer validity — 20–25 years is common.

What happens when a cert expires

The moment a certificate passes its "Not After" date, every browser in the world immediately starts showing security warnings to your visitors. There is no grace period. This is why certificate monitoring and timely renewal is critical.

13. SANs and wildcard certificates

Subject Alternative Names (SANs)

Modern certificates use Subject Alternative Names (SANs) to list all the domain names the certificate covers. A single certificate can cover multiple domains — for example:

• example.com
• www.example.com
• api.example.com
• example.net

The old method of putting the primary domain in the Common Name (CN) field is still present for compatibility, but browsers now rely on SANs. If a domain isn't in the SANs list, the certificate doesn't cover it — even if it's in the CN.

Wildcard certificates

A wildcard certificate is a special type that covers a whole subdomain level using an asterisk: *.example.com. This covers www.example.com, mail.example.com, api.example.com — any single subdomain under example.com.

A wildcard does not cover the root domain (example.com itself) or multiple levels of subdomains (dev.api.example.com). For those, you'd need separate SANs or a multi-domain certificate.

14. Fingerprints and serial numbers

Fingerprint

A certificate fingerprint is a hash of the entire certificate. It's used to uniquely identify a specific certificate. Even a tiny change to the certificate produces a completely different fingerprint. The two most common fingerprint algorithms are:

• SHA-1 — older, 40 hex characters. Still widely shown for reference but SHA-1 itself is considered weak for signing.
• SHA-256 — current standard, 64 hex characters. Use this when comparing certificates.

Fingerprints are useful when you want to confirm that the certificate on a server is exactly the one you issued, or to compare two certificates to see if they are identical.

Serial Number

Every certificate has a serial number assigned by the CA. It uniquely identifies the certificate within that CA's records. Serial numbers are used in certificate revocation — when a CA publishes a Certificate Revocation List (CRL), it lists serial numbers of revoked certificates.

15. Decode and inspect your certificate

Now that you understand what's inside an SSL certificate, you can inspect any certificate or CSR using our free tool:

• Paste / Upload tab — Decode any PEM, DER, CRT, CER, P7B, or CSR file. See all fields, SANs, fingerprints, key info, and extensions.
• Check URL tab — Enter any domain to fetch and decode its live certificate chain directly from the server.
• CSR vs Cert tab — Paste both your original CSR and your issued certificate to verify all fields were carried over correctly during signing.