SSL/TLS Certificates Explained

If you’ve ever seen a padlock icon next to a website URL, you’ve encountered SSL/TLS in action. But what are these certificates really? Why do they matter? And how do they work under the hood?

In this post, we’ll break down the essentials of SSL/TLS certificates.

What is an SSL/TLS Certificate?

An SSL/TLS certificate is a small digital file that helps:

• Encrypt data between your browser and a website
• Authenticate the identity of the server
• Enable HTTPS instead of HTTP

It’s like an ID card + a secret handshake: it proves who the server is and ensures no one else can read your conversation.

SSL (Secure Sockets Layer) is the old name. Today, it’s actually TLS (Transport Layer Security) — but “SSL” still sticks around in common use.

Who Issues These Certificates?

To make certificates trustworthy, they’re issued by special organizations called Certificate Authorities (CAs).

Examples of CAs:

• Let’s Encrypt (free, automated)
• DigiCert
• GlobalSign
• Entrust
• Sectigo

When you visit a website, your browser checks whether the certificate was signed by a trusted CA. If it is, the connection proceeds. If not, you get a warning like: “Your connection is not private.”

Types of Certificates

1. Public (CA-issued) Certificates

• Issued by a trusted CA
• Used for websites, APIs, apps
• Trusted by all browsers and systems

2. Self-Signed Certificates

• Generated by the site owner
• Not trusted by browsers by default
• Good for internal testing/dev only

3. Partner-Supplied Certificates

• Issued by or through a partner
• Used in B2B or internal system integrations
• Sometimes signed by private CAs, which need to be manually trusted

Where Are Certificates Used and Verified?

SSL/TLS certificates are not just created — they are used by systems to either present their identity or to verify someone else’s.

Here’s how it works in practice:

Systems That Present Certificates

These systems use certificates to prove their identity during a secure connection. Think of them as saying, “Here’s who I am — check me.”

• Web servers (e.g., Nginx, Apache, IIS) — serve websites securely
• Load balancers (e.g., F5, HAProxy) — manage traffic and terminate SSL connections
• Application servers — serve secure APIs or backend services
• Mobile apps or clients — may present client certificates during mTLS or certificate pinning

These systems are active participants, presenting their certificate to clients like browsers, apps, or APIs.

Systems That Verify Certificates (Trust Stores)

To accept a connection, the receiving system must verify the other party’s certificate. This is done using a trust store.

A trust store is a built-in list of trusted Root Certificate Authorities (CAs). If the certificate received was issued (directly or indirectly) by one of these trusted CAs, the connection is allowed.

Where do trust stores exist?

• Web browsers — maintain their own list of trusted CAs
• Operating systems — update and maintain a trust store system-wide
• Java apps — use a truststore file like cacerts or .jks
• APIs, CLI tools, or agents — may rely on system or custom trust stores

If a system can’t verify the certificate (because it doesn’t trust the CA), it blocks the connection and shows an error.

Trust Chain & Validation

When you connect to a secure website (https://example.com), your browser doesn’t just take the certificate at face value. It checks whether the certificate can be trusted, and this process involves a chain of certificates and something called a trust store.

Here’s what happens:

1. The website presents its SSL certificate. This includes information about the domain and the Certificate Authority (CA) that issued it.
2. Most certificates are not issued directly by a Root CA, but by an Intermediate CA, which itself was issued by a Root CA.
3. Your trust store — a built-in list of trusted Root CAs maintained by your operating system or browser — is then checked.
4. If your browser can follow a chain like this:

Website Certificate
    ↓ 
Intermediate CA
    ↓ 
Root CA (trusted by your computer)

then it trusts the website, and the secure connection is allowed.

If this chain is broken — for example, if the Root CA isn’t trusted, or if any certificate is missing or expired — the browser will show a warning or block the site.

Certificate Expiration & Renewal

Every certificate has a validity period, often 90 days (Let’s Encrypt) to 1–2 years (paid CAs). After that, it expires and must be renewed.

Expired certs = broken HTTPS, trust warnings.

Many teams use automation tools like:

• Certbot (for Let’s Encrypt)
• ACME protocol
• HashiCorp Vault
• Ansible or shell scripts for bulk renewal

Summary