How SSL/TLS certificates secure connections

The Interview Question

Interviewer: "Your team is deploying a new microservice that needs to communicate securely with both external clients over HTTPS and internal services using mTLS. Walk me through what a TLS certificate actually contains, how the browser verifies it, and how certificate revocation works when a private key gets compromised."

This question tests whether you understand the full lifecycle of TLS certificates, from issuance to verification to revocation. The interviewer wants depth beyond "HTTPS means encrypted." They want to hear you explain the chain of trust, the TLS handshake, and the real-world complexity of revocation. Candidates who only say "it encrypts the connection" miss the trust model entirely.

What to Clarify Before Answering

You: "Let me scope this to make sure I cover what matters..."

• "Are we talking about publicly-trusted certificates (Let's Encrypt, DigiCert) or an internal PKI with a private CA?"
• "Should I focus on TLS 1.2, TLS 1.3, or both? The handshake differs significantly between them."
• "Is the mTLS question about service mesh (like Istio) or direct certificate management?"
• "Are we concerned with certificate pinning, or just standard chain validation?"
• "Should I cover the ACME protocol for automated certificate issuance?"

Why this matters: The certificate ecosystem has many layers. A publicly-trusted certificate from Let's Encrypt follows a completely different issuance path than an internal certificate from a corporate CA. TLS 1.3 removed an entire round trip from the handshake. Scoping your answer shows you understand these distinctions.

The 30-Second Answer

A TLS certificate is a digitally signed document that binds a public key to an identity (typically a domain name). The certificate is signed by a Certificate Authority (CA) that the client trusts. Trust flows through a chain: the server's leaf certificate is signed by an intermediate CA, which is signed by a root CA that ships pre-installed in the client's trust store. During the TLS handshake, the client verifies this chain, checks that the certificate is not expired or revoked, and then uses the certificate's public key to establish an encrypted session. Revocation is handled through Certificate Revocation Lists (CRLs), OCSP (Online Certificate Status Protocol), or more commonly OCSP stapling where the server pre-fetches its own revocation status. Modern improvements include Certificate Transparency logs that make all issued certificates publicly auditable, catching mis-issuance quickly.

The Architecture Overview

The entire TLS certificate system rests on a hierarchy of trust. Root CAs are the anchors: they are self-signed certificates that ship with every operating system and browser. There are roughly 150 root CAs trusted by major browsers. Each root CA signs intermediate CAs, and intermediate CAs sign the leaf certificates that servers actually use.

I find the most important thing to understand is that root CAs never directly sign leaf certificates in modern practice. The root CA's private key is kept offline in hardware security modules (HSMs). Intermediate CAs handle the day-to-day signing. If an intermediate CA is compromised, only that intermediate can be revoked without destroying trust in the root.

The separation between the certificate (public, sent to every client) and the private key (secret, never leaves the server) is fundamental. The certificate proves identity. The private key proves you are the entity named in the certificate.

X.509 Certificate Structure: What Is Inside a Certificate

Every TLS certificate follows the X.509 v3 standard. Understanding its fields is essential for debugging certificate errors in production.

Subject and Subject Alternative Names (SANs). The Subject field historically contained the domain name in the Common Name (CN) field. Modern certificates use SANs instead, which allow a single certificate to cover multiple domains and wildcards. Browsers today ignore the CN and only check SANs. If your certificate has CN=example.com but no SAN entry for example.com, the browser will reject it.

Validity period. Certificates have a limited lifetime. The current industry standard is 90 days (Let's Encrypt) to 398 days (maximum for publicly-trusted certificates). Shorter lifetimes reduce the window of exposure if a private key is compromised. They also force automation, which is a good thing.

Key Usage and Extended Key Usage. These extensions restrict what the certificate can be used for. A leaf certificate has CA: FALSE in Basic Constraints, meaning it cannot sign other certificates. An intermediate CA has CA: TRUE. Mixing these up is a common misconfiguration that causes hard-to-debug failures.

Authority Information Access (AIA). This extension tells the client where to find the OCSP responder and where to download the issuing CA's certificate. If the server does not send the full certificate chain, the client uses the AIA URL to fetch the missing intermediate certificate.

Certificate Types: DV, OV, EV

• Domain Validation (DV): CA verifies you control the domain (via DNS record or HTTP challenge). Cheapest. Automated via ACME. Sufficient for 99% of use cases.
• Organization Validation (OV): CA verifies the organization exists (business records check). Adds organization name to the certificate. Minimal practical benefit over DV.
• Extended Validation (EV): CA performs thorough business verification. Used to show a green bar in browsers, but most browsers removed the visual distinction. I do not recommend paying the premium for EV anymore.

For your interview: say "DV certificates validated via ACME are the standard. OV and EV add identity verification but browsers no longer visually distinguish them."

Certificate Issuance: From CSR to Signed Certificate

The issuance process starts with the server generating a key pair and sending a Certificate Signing Request (CSR) to the CA. Let me walk through both the manual flow and the automated ACME flow.

Step 1: Key generation and CSR. The server generates a private key (RSA 2048+ or ECDSA P-256/P-384) and creates a CSR containing the public key, domain name, and optionally organization details. The CSR is signed with the private key to prove the requester possesses it.

Step 2-3: Domain validation. For DV certificates, the CA needs proof that you control the domain. Two common methods:

• HTTP-01: Place a token file at http://yourdomain/.well-known/acme-challenge/{token}. The CA fetches it.
• DNS-01: Create a TXT record at _acme-challenge.yourdomain with a specific value. This is the only method that supports wildcard certificates.

Step 4-5: Certificate Transparency. Before issuing the certificate, the CA submits a "pre-certificate" to multiple CT logs and receives Signed Certificate Timestamps (SCTs). Chrome requires at least 2-3 SCTs from different CT logs. This makes every certificate issuance publicly auditable.

Step 6: Certificate delivery. The CA signs the certificate with its intermediate CA private key and returns it along with the intermediate certificate chain.

ACME and Let's Encrypt

The ACME (Automatic Certificate Management Environment) protocol automates the entire issuance flow. Tools like Certbot or Caddy implement ACME to automatically request, validate, install, and renew certificates without human intervention.

I consider ACME the single biggest improvement to internet security in the past decade. Before Let's Encrypt (launched 2015), certificates cost $50-200/year and required manual renewal. Now they are free and auto-renew every 60 days. There is no excuse for not using HTTPS.

The TLS Handshake: Establishing a Secure Connection

The TLS handshake is where the certificate gets verified and the encryption keys get established. I will cover TLS 1.3 as the primary flow (TLS 1.2 is similar but adds a round trip).

ClientHello. The client sends supported TLS versions, cipher suites, and (in TLS 1.3) an ECDHE key share. The Server Name Indication (SNI) extension tells the server which hostname the client wants, allowing multiple certificates on a single IP address.

ServerHello and Certificate. The server picks a cipher suite, sends its key share, and delivers the certificate chain. In TLS 1.3, everything after ServerHello is encrypted using keys derived from the ECDHE exchange.

CertificateVerify. This is critical and often overlooked in explanations. The server signs the handshake transcript with its private key. The client verifies this signature using the public key from the certificate. This proves the server actually possesses the private key corresponding to the certificate, not just a copy of the certificate itself.

Chain verification. The client walks up the chain: leaf is signed by intermediate, intermediate is signed by root, root is in the trust store. At each step, the client verifies the cryptographic signature and checks that the signer certificate has CA: TRUE in Basic Constraints.

Key derivation. Both sides combine the ECDHE shared secret with handshake parameters to derive session keys using HKDF. This gives forward secrecy: even if the server's long-term private key is later compromised, past sessions cannot be decrypted because the ephemeral ECDHE keys are discarded after the handshake.

For your interview: the key phrase is "forward secrecy via ephemeral ECDHE." This means each session generates unique encryption keys. Compromising the server's certificate private key does not allow decryption of recorded past sessions.

Certificate Revocation: What Happens When Keys Are Compromised

Revocation is the hardest problem in the certificate ecosystem. When a private key is compromised, you need to tell every client in the world to stop trusting that certificate before its expiry date. There is no perfect solution.

Certificate Revocation Lists (CRLs)

The CA publishes a list of revoked certificate serial numbers at a URL specified in the certificate's CRL Distribution Points extension. Clients download this list periodically and check it before trusting a certificate.

The problem: CRLs grow large (major CAs have lists with millions of entries), downloads happen over unencrypted HTTP, and clients that cannot fetch the CRL often "soft-fail" (proceed anyway). In practice, CRLs alone do not provide reliable revocation.

OCSP (Online Certificate Status Protocol)

Instead of downloading the entire revocation list, the client asks the CA's OCSP responder about a specific certificate: "Is serial number X still valid?" The responder answers "good," "revoked," or "unknown."

The problem: OCSP adds latency to every new connection (the client must contact the CA before proceeding). It leaks browsing history to the CA (the CA sees which sites you visit). And if the OCSP responder is down, most browsers soft-fail and accept the certificate anyway.

OCSP Stapling (The Practical Solution)

With OCSP stapling, the server periodically fetches its own OCSP response from the CA and "staples" it to the TLS handshake. The client receives the revocation proof directly from the server, eliminating the latency of an OCSP lookup and the privacy concern of contacting the CA.

CRLite (The Emerging Approach)

Firefox developed CRLite, which compresses the entire set of revoked certificates into a small filter (~1-10MB) that ships with browser updates. This gives real-time revocation checking with no network requests and no privacy leakage. I expect other browsers to adopt similar approaches.

Certificate Transparency: Public Audit Logs

Certificate Transparency (CT) is a system of public, append-only logs that record every certificate issued by participating CAs. After a CA signs a certificate, it submits the certificate to multiple independent CT log servers and receives Signed Certificate Timestamps (SCTs).

Browsers (Chrome, Safari) require certificates to include SCTs from at least 2-3 CT logs. If a CA issues a fraudulent certificate (intentionally or through compromise), it appears in the CT logs and can be detected by domain owners monitoring for unauthorized certificates.

I consider CT the most effective defense against CA compromise. In 2015, Google discovered that CNNIC (a Chinese root CA) had issued unauthorized certificates for Google domains. CT logs made this detectable. Without CT, such attacks are invisible to the domain owner.

How to use CT in practice: Set up a CT monitor for your domains. Services like crt.sh or SSLMate's Cert Spotter will alert you if any CA issues a certificate for your domain that you did not request.

Mutual TLS (mTLS): Both Sides Authenticate

Standard TLS is one-sided: the client verifies the server's certificate, but the server accepts any client. Mutual TLS (mTLS) adds client certificates, so both sides authenticate each other.

mTLS is the standard for service-to-service communication in microservice architectures. Service meshes like Istio and Linkerd automate mTLS by injecting sidecar proxies that handle certificate issuance, rotation, and verification transparently.

The key difference from API keys: mTLS proves identity cryptographically. An API key is a shared secret that can be stolen and replayed. A client certificate proves the client holds a private key without ever transmitting it. Combined with short-lived certificates (hours, not years), mTLS provides much stronger authentication.

For your interview: "For internal service-to-service auth, I prefer mTLS over API keys because it provides cryptographic identity without shared secrets. Service meshes like Istio automate the PKI."

Certificate Pinning: The Controversial Approach

Certificate pinning restricts which certificates a client will accept for a given domain, beyond the normal chain validation. Instead of trusting any certificate signed by any CA in the trust store, the client only trusts a specific certificate or public key.

HTTP Public Key Pinning (HPKP): Deprecated

HPKP was a browser feature where servers sent a header (Public-Key-Pins) telling the browser to only accept specific public keys for future connections. It was deprecated and removed because:

• Hostile pinning: An attacker who briefly controls your DNS could pin their own key, permanently locking you out of your own domain.
• Foot-gun risk: If you lose access to your pinned key and backup key simultaneously, your site becomes unreachable with no recovery path.
• Operational burden: Key rotation required planning pin changes months in advance.

Native Mobile Pinning (Still Used)

Mobile apps can embed expected certificate pins in app code. This is useful for banking and high-security apps where you control both the client and server. The tradeoff is that updating pins requires an app store release.

I recommend pinning only for high-value targets (banking, healthcare) and only pinning the intermediate CA certificate (not the leaf), which gives you flexibility to rotate leaf certificates without app updates.

What Happens When Things Break

Performance Characteristics

CPU impact. Modern CPUs with AES-NI hardware acceleration make symmetric encryption essentially free. The TLS handshake (asymmetric crypto) is the expensive part, but it only happens once per connection. With connection reuse (HTTP/2 multiplexing, connection pooling), the amortized cost of TLS is negligible.

Certificate size. A typical certificate chain (leaf + intermediate) is 2-4KB. With RSA 4096-bit keys, the chain can reach 6-8KB. ECDSA P-256 certificates are significantly smaller (~1KB for the chain), which matters for mobile clients and initial connection latency.

Connection reuse matters more than handshake optimization. If your service creates a new TLS connection for every request, optimizing the handshake from 100ms to 50ms saves less than simply reusing connections. HTTP/2 multiplexing over a single TLS connection eliminates most handshake overhead. Optimize connection reuse before optimizing handshake performance.

How This Compares to Alternatives

I reach for TLS certificates when I need identity verification tied to a domain name and interoperability with any client. For internal service-to-service auth, mTLS with short-lived certificates (via a service mesh) is the gold standard. For simple API auth where identity verification is less critical, JWT tokens are lighter weight.

Interview Cheat Sheet

• When asked "what is a TLS certificate?": "A digitally signed document that binds a public key to a domain name. Signed by a CA that the client trusts. The certificate proves identity, the private key (never shared) proves possession."
• When asked "how does the chain of trust work?": "Root CAs ship in the OS/browser trust store. They sign intermediate CAs. Intermediaries sign leaf certificates. The client walks the chain from leaf to root, verifying each signature."
• When asked "what happens during a TLS handshake?": "Client sends supported ciphers and a key share. Server responds with its choice and certificate chain. Client verifies the chain and signature. Both derive session keys via ECDHE for forward secrecy."
• When asked "what is forward secrecy?": "Each session uses ephemeral ECDHE keys that are discarded after the handshake. Even if the server's long-term private key is later compromised, past recorded sessions cannot be decrypted."
• When asked about certificate revocation": "CRLs are too large and slow. Direct OCSP adds latency and leaks privacy. OCSP stapling is the practical solution: the server pre-fetches its revocation status and attaches it to the handshake."
• When asked about Let's Encrypt": "Free DV certificates issued via the ACME protocol. 90-day lifetime forces automation. Covers the vast majority of use cases. No reason to pay for DV certificates anymore."
• When asked about mTLS": "Both client and server present certificates. Provides cryptographic identity for service-to-service auth without shared secrets. Service meshes like Istio automate the PKI with short-lived certificates."
• When asked about Certificate Transparency": "Public append-only logs where CAs must record every certificate they issue. Browsers require SCTs from 2-3 logs. Makes unauthorized certificate issuance detectable."
• When asked about pinning": "HPKP is deprecated because of hostile pinning risk. Mobile apps still pin intermediate CA certs for high-security scenarios. For most services, standard chain validation plus CT monitoring is sufficient."
• When asked about TLS 1.3 improvements": "1-RTT handshake (vs 2-RTT in 1.2), removed insecure ciphers, enforced forward secrecy, added 0-RTT resumption for returning clients."

Test Your Understanding

Quick Recap

1. A TLS certificate binds a public key to a domain name, signed by a CA that clients trust.
2. Trust flows through a chain: leaf certificate, signed by intermediate CA, signed by root CA (pre-installed in client trust stores).
3. The TLS 1.3 handshake completes in 1 round trip, establishes forward secrecy via ephemeral ECDHE, and verifies the server's identity through the certificate chain.
4. Certificate revocation is imperfect: CRLs are too slow, OCSP adds latency, and OCSP stapling with must-staple is the best practical compromise.
5. Certificate Transparency logs make all certificate issuance publicly auditable, enabling detection of unauthorized certificates.
6. ACME (Let's Encrypt) has made certificate issuance free and automated, eliminating the primary reason certificates expire unexpectedly.
7. mTLS adds client certificates for mutual authentication, making it the standard for service-to-service communication in microservice architectures.
8. Short-lived certificates (24 hours in service meshes) reduce the importance of revocation because certificates expire before revocation can propagate.

Related Concepts

• Public key cryptography is the mathematical foundation that makes certificates possible, enabling encryption and digital signatures with asymmetric key pairs.
• DNS and domain resolution is tightly coupled with TLS through SNI (Server Name Indication), CAA records, and DNS-based validation for certificate issuance.
• Service meshes (Istio, Linkerd) automate mTLS certificate management for microservice architectures, handling the entire PKI lifecycle transparently.
• OAuth token flows use TLS as the transport layer security and sometimes use client certificates for service-to-service authentication in addition to tokens.
• API gateway security combines TLS termination, certificate verification, and request routing as the first line of defense for backend services.