What Are Digital Certificates? TLS, Certificate Authorities, and How Trust Works on the Internet

A Story: The Official ID Card

Imagine you are traveling to a foreign country. You arrive at the airport, and the immigration officer asks for your passport. You hand over a small booklet with your photo, name, date of birth, and a stamp from your home country's government.

The officer examines the passport. They look at the photo. They check the holograms. They verify that the document was issued by a trusted authority — your home country's government. They do not know you personally. They cannot verify your identity by looking at you. But they trust the passport because they trust the authority that issued it.

The passport is a certificate. It binds your identity (name, photo, date of birth) to a physical document. The government is the certificate authority — the trusted issuer. The holograms and security features make the passport tamper-evident. If someone tries to change your photo, it is obvious.

Now imagine visiting a website. Your browser doesn't know that server. The server presents a digital certificate. The certificate says: "This domain name (example.com) owns this public key." A public key is like a lockbox: anyone can use it to encrypt a message, but only the server with the matching private key can open it.

A trusted Certificate Authority(CA) has signed that statement.

Your browser checks three things:

1. Does the domain name match the one you typed?
2. Is the CA's signature valid? Your browser has a built-in list of trusted CAs (like DigiCert, Let's Encrypt). It checks who signed the certificate, finds that CA's public key in its list, and verifies the signature mathematically. If the math works, the signature is genuine and the certificate hasn't been tampered with. The browser doesn't just check the signature. It also checks that the domain name in the certificate exactly matches the domain name in the address bar. If an attacker presents Bob's certificate on bobs-bank-xyz.com, the browser compares bobs-bank.com (on the certificate) to bobs-bank-xyz.com (in the address bar). They don't match. The browser shows a warning and refuses to connect.
3. Has the certificate expired?

If all checks pass, your browser trusts the certificate. The browser and server now use the public key just once — to agree on a temporary session key that both will use. The browser encrypts that session key with the server's public key. Only the real server can decrypt it. Now both sides share the same session key, and they use it to encrypt all communication in both directions for the rest of the connection.

That's how trust works online — not through personal knowledge, but through certificates and trusted authorities.

Part One: What Is a Digital Certificate?

A digital certificate (also called a public key certificate or identity certificate) is an electronic document that proves the ownership of a public key and binds that public key to an identity — such as a domain name, organization name, or individual person.

In simpler terms: a digital certificate is like a passport for a server, application, or person. It says: "This public key belongs to this entity, and a trusted authority has verified this binding."

What problem does a certificate solve?

Recall from the article on public and private keys: if Alice wants to send an encrypted message to Bob, she needs Bob's public key. But how does she know that the public key she has actually belongs to Bob? An attacker could give her a fake public key and intercept the message.

A digital certificate solves this problem. A trusted third party — a Certificate Authority (CA) — verifies that the public key belongs to Bob and issues a certificate attesting to that fact.

The certificate contains three key things:

1. Bob's name
2. Bob's public key
3. The CA's digital signature over both

Now Alice receives Bob's certificate. But how does she verify it?

Alice's computer has a built-in list of trusted CAs — including the one that signed Bob's certificate. Her computer uses that CA's public key (which is already in the trust list) to check the signature on Bob's certificate. If the signature is valid, Alice knows two things: the certificate was really issued by that CA, and it hasn't been tampered with.

Because Alice trusts the CA, she now trusts that Bob's public key really belongs to Bob. She encrypts her message with that public key and sends it.

Part Two: What a Digital Certificate Contains

A digital certificate is not just a public key. It contains a set of structured information, defined by the X.509 standard — the most common certificate format used across the internet today.

The core fields of an X.509 certificate:

1. Subject. Who or what the certificate belongs to. For a website certificate, this includes the domain name (Common Name or CN) and sometimes the organization name.
2. Public key. The public key being certified. This is the actual cryptographic key that will be used for encryption or signature verification.
3. Issuer. The Certificate Authority that issued the certificate. This identifies the trusted third party that vouches for the binding.
4. Validity period. The certificate is valid only between a specific start date and end date. Modern certificates are typically valid for 90 days to one year.
5. Serial number. A unique identifier assigned by the CA. Used for tracking and revocation.
6. Signature algorithm. The algorithm the CA used to sign the certificate (for example, SHA-256 with RSA).
7. Signature. The CA's digital signature over the certificate contents. This is what makes the certificate tamper-evident. If any field is changed after signing, the signature becomes invalid.
8. Key usage and extended key usage. What the public key is allowed to be used for — for example, TLS server authentication, code signing, or email encryption.
9. Subject Alternative Name (SAN). Additional domain names or identities associated with the certificate. Modern browsers require SAN for multi-domain certificates.
10. Optional fields include the legal organization name, department, city, state, and two-letter country code. The Organizational Unit (OU) field is deprecated and not recommended in new certificates.

Part Three: Certificate Authorities — The Trust Anchors

A Certificate Authority (CA) is a trusted organization that issues digital certificates. Browsers and operating systems come with a built-in list of trusted CAs called the trust store or root store. If a certificate is signed by a CA in the trust store, your browser will accept it without complaint.

How CAs work:

The CA verifies the identity of the certificate requester — how thoroughly depends on the certificate type, covered in Part Five. The CA then issues a certificate binding the requester's identity to their public key, and signs that certificate with its own private key. Anyone with the CA's public key can verify the signature, confirming the certificate is authentic and unmodified.

Types of CAs:

Public CAs are commercial organizations that issue certificates to anyone who can prove ownership of a domain. Examples include DigiCert, Let's Encrypt, GlobalSign, and Sectigo.

Private CAs are run by organizations for internal use. They are not trusted by public browsers, but can be added to internal trust stores — common in enterprise environments.

Root CAs are the top-level CAs whose public keys are built directly into browsers and operating systems. They are the ultimate trust anchors of the entire system.

Intermediate CAs are CAs signed by root CAs. Most publicly trusted certificates are issued by intermediate CAs, not root CAs directly. This provides an important security layer: if an intermediate CA is compromised, the root CA can revoke it without affecting every root certificate on every device in the world.

Part Four: The Certificate Chain — Building Trust

Certificates are rarely signed directly by a root CA. Instead, they form a chain of trust.

How validation works:

The server presents its leaf certificate, often accompanied by any intermediate certificates needed to complete the chain. The client — your browser — starts from the leaf and works upward. It verifies the leaf's signature using the intermediate CA's public key, then verifies the intermediate's signature using the root CA's public key. Because the root CA is in the trust store, the chain is trusted.

Why multiple levels?

Security is the primary reason. Root CA private keys are kept offline and used as rarely as possible. Intermediate CAs handle the day-to-day work of issuing certificates. If an intermediate CA is compromised, the root CA can revoke just that intermediate without disrupting the entire trust infrastructure. Different intermediate CAs can also be scoped to different purposes — TLS, code signing, email — and replaced or rotated independently.

Part Five: Types of Certificates by Validation Level

Not all certificates are created equal. The validation level describes how thoroughly a CA has verified the identity behind the certificate before issuing it.

Domain Validation (DV)

The CA verifies only that the requester controls the domain. This is typically done by responding to an email at a domain-specific address, adding a DNS TXT record, or placing a verification file on the web server.

What it proves: you control the domain. Nothing about the organization or individual behind it.

Validation is fast — often minutes to a few hours — and DV certificates are free from Let's Encrypt or very low cost from commercial CAs. They are the right choice for personal websites, blogs, internal tools, and any site that needs encryption but does not need to communicate organizational identity to users. In the browser, you will see a padlock icon and nothing more.

Organization Validation (OV)

The CA verifies domain ownership plus the legal existence of the organization. The CA checks business registration records, government databases, and may call the organization directly.

What it proves: you control the domain and your organization is legally registered.

Validation typically takes a few days. OV certificates are appropriate for business websites and e-commerce where users should know they are dealing with a real company. The organization name is visible in the certificate details, though browsers do not surface it prominently in the address bar.

Extended Validation (EV)

The CA performs a rigorous verification of the organization's legal existence, physical address, operational status, and the authority of the person requesting the certificate. This is the highest level of assurance available.

What it proves: you control the domain, your organization is legally registered and actively operating, and the requester is authorized to act on behalf of the organization.

Validation can take days to weeks and costs significantly more. EV certificates are appropriate for banks, financial institutions, and high-value e-commerce where trust is critical. All major browsers removed the prominent green address bar treatment for EV certificates by 2019, so the visual distinction is now limited to certificate details — but the underlying organizational verification remains meaningful.

Part Six: Types of Certificates by Use Case

Certificates serve many purposes beyond website authentication.

TLS/SSL Server Certificate. The most common certificate type. Used to secure HTTPS websites. Binds a domain name (or multiple domain names) to a public key. The server presents this certificate during the TLS handshake. Wildcard certificates (for example, *.example.com) are a common variant that cover all subdomains of a domain with a single certificate — convenient but worth understanding, since a compromised wildcard key affects every subdomain at once.

TLS/SSL Client Certificate. Used to authenticate a client — a user, device, or service — to a server. The client holds a private key and presents a certificate. The server verifies the certificate to identify the client. Common in enterprise environments, mutual TLS (mTLS) for service-to-service communication, and government systems.

Code Signing Certificate. Used to sign software executables, installers, and scripts. The signature proves the software came from the stated publisher and has not been tampered with since signing. Operating systems display a "Verified Publisher" label when running signed software, and will warn users if software is unsigned.

Email (S/MIME) Certificate. Used to sign and encrypt email. Binds an email address to a public key. Recipients can verify the sender's signature — proving the email came from the claimed address — and encrypt replies back.

Document Signing Certificate. Used to sign PDFs and other documents, creating a digital signature that is legally binding in many jurisdictions. Used for contracts, invoices, and official records.

Device Certificate. Used to authenticate IoT devices, network equipment, and other hardware. Often embedded during manufacturing. Ensures that only authorized devices can connect to a network.

Choose DV for personal sites and internal tools where only encryption matters. Choose OV for business websites where users should know they are dealing with a real company. Choose EV for banks and high-value transactions where the highest assurance is warranted.

Part Seven: How Certificates Are Used in TLS

The most common use of certificates is in TLS (Transport Layer Security) — the protocol that secures HTTPS. Here is a simplified view of how the TLS handshake works, focusing on the certificate's role.

Client Hello. Your browser sends a list of supported cipher suites and a random number.

Server Hello. The server chooses a cipher suite and sends its own random number.

Certificate. The server sends its TLS certificate, containing its public key and the domain name.

Certificate Verification. Your browser verifies four things: the certificate has not expired; the domain name matches the site you are visiting; the signature chain validates to a trusted root CA in your trust store; and the certificate has not been revoked.

Key Exchange. Browser and server use a key exchange mechanism — in modern TLS 1.3, this is always ephemeral Diffie-Hellman — to establish a shared secret without ever transmitting it directly.

Session Keys. Both sides derive symmetric session keys from the shared secret and the random numbers exchanged earlier.

Finished. Both sides switch to encrypted communication using those session keys.

The certificate is critical in the verification step. Without it, your browser would have no way to know whether it is talking to the real website or an imposter performing a man-in-the-middle attack.

Part Eight: Certificate Revocation — When Trust Must Be Broken

Certificates expire, but sometimes trust needs to be revoked earlier. A private key might be stolen, or a domain might change hands.

The problem: how does your browser know a certificate is no longer trustworthy before it expires?

There are several technical solutions — CRL, OCSP, OCSP stapling, and browser-maintained lists — but they all aim to do the same thing: let the browser check whether a certificate has been revoked.

Each approach has trade-offs between speed, privacy, and reliability. Some require the browser to ask the CA directly (which adds latency and reveals which sites you visit). Others push lists of revoked certificates to your browser in advance (which is faster and private but less real-time).

What you need to know for now: Revocation exists. Browsers check for it. No system is perfect, but modern browsers combine multiple methods to make revocation checking fast, private, and reliable enough for everyday use.

Part Nine: Self-Signed Certificates — Trust Without a CA

A self-signed certificate is signed by its own private key rather than by a CA. There is no trusted third party vouching for its authenticity.

When self-signed certificates are appropriate:

Development and testing environments are the primary use case. Localhost and internal test systems can use self-signed certificates; browsers will show a security warning, but you can bypass it for development purposes. Self-signed certificates can also work in closed private networks where trust is established through device enrollment rather than public CAs.

The problem with self-signed certificates in production:

Browsers do not trust them by default. Users see a full-page warning — "Your connection is not private" — and must manually add an exception. Worse, if users are trained to click through certificate warnings, they become desensitized to warnings that represent real attacks.

More fundamentally, without a CA, there is no trusted third party to verify that the certificate belongs to the claimed domain. An attacker could create a self-signed certificate for yourbank.com, and your browser would have no basis to distinguish it from the real one. The CA system exists precisely to prevent this.

Part Ten: Let's Encrypt — Free and Automated Certificates

Let's Encrypt is a non-profit Certificate Authority that provides free, automated, domain-validated certificates. Since launching in 2016, it has transformed the TLS landscape.

Before Let's Encrypt, obtaining a certificate was expensive and required manual renewal every year or two. Many websites — particularly smaller ones — ran without HTTPS because the cost and complexity were not worth it for a blog or personal project. Let's Encrypt eliminated both barriers.

Why 90-day certificates?

Let's Encrypt certificates are valid for 90 days, shorter than the one-to-two year lifetimes common elsewhere. This is intentional. Short lifetimes limit the damage from a compromised key and force operators to automate renewal rather than treat it as an occasional manual task. Automation is the point: a well-configured server should never have an expired certificate.

Part Eleven: Certificate Lifecycle Management

Managing certificates across an organization is a significant operational challenge — one that is easy to underestimate until something expires.

The certificate lifecycle:

The lifecycle runs from generating a key pair and Certificate Signing Request (CSR), through submission to a CA and the validation process, to issuance and installation. From there it enters an ongoing phase of monitoring expiration dates, renewing before they are reached, and revoking promptly if a private key is compromised.

Common problems:

Expired certificates cause outages. A site with an expired certificate is inaccessible to modern browsers, which treat an expired certificate as a hard error rather than a warning. Many significant outages at well-known organizations have been traced to a certificate that nobody was watching.

Manual management does not scale. Spreadsheets and calendar reminders fail. When an organization has hundreds of certificates across many systems, automated tracking and renewal become essential.

Solutions:

The ACME protocol, used by Let's Encrypt, can be adopted with any ACME-compatible CA to automate issuance and renewal across your infrastructure. At enterprise scale, dedicated certificate lifecycle management platforms — Venafi and AppViewX are common examples — provide inventory, monitoring, and workflow automation. At minimum, monitor your certificates and set alerts well in advance of expiration.

Part Twelve: Certificate Transparency — Making Issuance Public

Certificate Transparency (CT) is a system that makes certificate issuance public and auditable. Its purpose is to detect when a CA issues a certificate fraudulently — for example, issuing a certificate for a domain without the owner's permission.

Before CT, a CA could issue a certificate for any domain, and the domain owner would have no way to discover it had happened. A rogue CA or one that had been compromised could silently issue certificates enabling interception of traffic to any site.

How CT works:

CAs must log every certificate they issue to one or more public, append-only cryptographic logs. These logs provide verifiable proofs of inclusion. The proof — called a Signed Certificate Timestamp, or SCT — is embedded in the certificate itself or delivered during the TLS handshake. Browsers verify that SCTs are present and valid. Domain owners can monitor logs for unauthorized certificates issued for their domains.

Browsers now require CT compliance. A certificate without valid SCTs will not be trusted.

Part Thirteen: Common Certificate Mistakes

Letting certificates expire. The most common and most avoidable certificate failure. Monitoring is not optional. Automate renewal everywhere you can, and set multiple alerts with enough lead time to intervene if automation fails.

Using self-signed certificates in production. Your users see security warnings. They learn to click through them. This trains them to ignore warnings that indicate real attacks. Use CA-issued certificates in production — free ones from Let's Encrypt if cost is a concern.

Weak key sizes. This refers to the public/private key pair inside the certificate — specifically, the key you generate on your own server before sending a Certificate Signing Request (CSR) to the CA. The CA doesn't create your key pair. You do. Then you send only your public key to the CA for signing.

So what can you do? When you generate your key pair (using tools like OpenSSL or your web server software), choose a strong key size. For RSA, use at least 2048 bits. Better yet, use ECDSA with P-256 or P-384 — it's stronger, faster, and produces smaller keys.

The CA will happily sign whatever key you give them. If you send a weak 1024-bit key, they'll still issue a certificate. The weakness is your responsibility.

Long certificate lifetimes. Certificates valid for two or more years are an outdated practice. Shorter lifetimes — 90 days to one year — limit the window of exposure if a key is compromised and force the automation that makes certificate management reliable.

Not protecting private keys. The certificate is public. The private key is not. A certificate whose private key is compromised must be revoked immediately and reissued. Store private keys securely — ideally in a Hardware Security Module (HSM) or managed key service — and never store them alongside the certificates they protect.

Part Fourteen: Digital Certificates in the Unbroken Chain

Recall the Unbroken Chain from Article 1. Digital certificates are the foundation of trust at the network layer.

When your browser connects to a website over HTTPS, it verifies the server's certificate before a single byte of application data is exchanged. When services communicate with each other over mutual TLS (mTLS), both sides present certificates and verify each other's identity. When you run an installer, your operating system checks the software publisher's code signing certificate before allowing execution. When you open a signed email, your client verifies the sender's certificate before marking the signature as valid.

In each case, the mechanism is the same: a small set of root CAs that browsers and operating systems trust unconditionally, a chain of intermediate CAs they have signed, and leaf certificates that bind cryptographic keys to the identities of real servers, organizations, and people.

Part Fifteen: What You Should Take Away

After reading this article, you should understand that digital certificates are the mechanism for binding public keys to identities, with trust established through a hierarchy of Certificate Authorities.

You should be able to explain what a digital certificate is — an electronic document that binds a public key to an identity — and describe what it contains: subject, public key, issuer, validity period, signature, key usage, and SANs.

You should understand the role of Certificate Authorities as trusted third parties, the structure of the certificate chain from root to intermediate to leaf, and why that hierarchy exists.

You should be able to distinguish the three validation levels — DV for domain control, OV for organizational identity, EV for extended organizational verification — and identify the major certificate types: TLS server, TLS client, code signing, S/MIME, document signing, and device certificates.

You should recognize when self-signed certificates are appropriate and when they are not, appreciate what Let's Encrypt changed about the economics of certificate issuance, and know the common mistakes that lead to outages and security failures.

And most importantly, you should understand that digital certificates are the foundation of trust on the internet. Without them, your browser would have no way to know if it is talking to the real yourbank.com or an imposter. The CA system has real flaws — CAs have been compromised, certificates have been issued fraudulently — but Certificate Transparency, short lifetimes, and automated management have made it substantially more robust. It is the system we have, and it secures trillions of transactions every day.

Closing: The Passport Revisited

Your passport is not just a document. It is a claim: "I am this person." The claim is backed by the authority of your home country's government. The government verified your identity before issuing the passport. The security features prevent tampering. When you present your passport, the immigration officer does not need to know you personally. They trust the passport because they trust the authority that issued it.

A digital certificate is the same. The certificate claims: "This public key belongs to this domain or organization." The claim is backed by a Certificate Authority. The CA verified the domain ownership or organization identity before issuing the certificate. The CA's signature prevents tampering. When your browser receives the certificate, it does not need to know the server personally. It trusts the certificate because it trusts the CA that issued it.

The passport system has flaws. Passports can be forged. But for most purposes, the system works.

The certificate system has flaws. CAs have been compromised. Certificates have been issued fraudulently. But Certificate Transparency makes those failures detectable, and the industry has built tooling to respond quickly when they occur.

Understanding the system — its strengths, its weaknesses, its nuances — is essential to understanding how trust works on the internet. Not perfect trust. Not absolute trust. But enough trust for the web to function.