Skip to content

TLS & HTTPS — Interview Questions

A staged bank of interview questions on TLS and HTTPS: from the three security guarantees a junior must recite, through handshake mechanics and certificate validation, to the staff-level judgment calls around TLS termination, mTLS, and version deprecation. Each answer is written to be said out loud in an interview — precise, structured, and honest about trade-offs.

Table of Contents

Junior Questions

Q1: What are the three guarantees TLS provides?

TLS provides confidentiality, integrity, and authentication.

  • Confidentiality: data is encrypted, so a network eavesdropper sees only ciphertext, not the plaintext of your request or response.
  • Integrity: data cannot be tampered with in transit without detection. Every record carries an authentication tag; if a byte is flipped, the receiver rejects the record.
  • Authentication: you can verify you are talking to the server you intended (via its certificate), not an impostor. TLS optionally authenticates the client too (mTLS).

A useful way to remember why all three are needed: confidentiality alone stops eavesdropping but not tampering; integrity alone stops tampering but not eavesdropping; and both are worthless if you established the encrypted channel with an attacker in the first place — that is what authentication prevents.

Q2: What is the difference between HTTP and HTTPS?

HTTPS is just HTTP running inside a TLS-encrypted channel. The HTTP semantics — methods, headers, status codes, bodies — are identical. What changes is the transport underneath: instead of sending HTTP directly over TCP in plaintext, the client first performs a TLS handshake over TCP, and then all HTTP bytes flow through the encrypted TLS session.

The layering is: HTTP → TLS → TCP → IP. HTTP does not know or care that TLS is there; TLS presents a reliable, ordered, encrypted byte stream that looks like a socket. This clean separation is why almost any protocol (SMTP, IMAP, gRPC) can be "TLS-ified" the same way. The visible differences are the https:// scheme and default port 443 instead of 80.

Q3: Why do we need both symmetric and asymmetric cryptography in TLS?

They solve different problems and have different costs.

  • Asymmetric (RSA, ECDSA, Diffie-Hellman) lets two parties who have never met agree on a shared secret over an open channel, and lets a server prove its identity with a certificate. It solves the bootstrapping problem. But it is computationally expensive — orders of magnitude slower per byte.
  • Symmetric (AES-GCM, ChaCha20-Poly1305) is fast and cheap and used for the actual bulk data. But it requires both sides to already share a secret key.

So TLS uses asymmetric crypto once, during the handshake, to authenticate the server and establish a shared symmetric key. Then it switches to symmetric crypto for the rest of the connection. You get the trust properties of public-key crypto with the throughput of symmetric ciphers.

Q4: What is a TLS certificate and what does it contain?

A certificate is a signed statement binding a public key to an identity. The key fields are:

  • Subject / SAN (Subject Alternative Name): the domain name(s) this cert is valid for, e.g. example.com, *.example.com. Browsers match the requested hostname against the SAN, not the legacy Common Name.
  • Public key: the server's public key (RSA or EC).
  • Issuer: which CA signed this certificate.
  • Validity period: not-before and not-after timestamps.
  • Signature: the issuer's cryptographic signature over the whole certificate.

The certificate itself is public — it is sent to every client. Its security comes from the CA's signature: only the CA's private key could have produced it, and the client trusts the CA. The server proves it owns the matching private key during the handshake.

Q5: What does the padlock in the browser actually mean?

It means three narrow things: the connection is encrypted, the certificate presented is currently valid, and it chains to a CA the browser trusts for the hostname in the address bar. That is it.

It does not mean the site is safe, honest, or malware-free. A phishing site can trivially obtain a valid certificate for its own domain and show a padlock. The padlock says "you have a private, authenticated channel to whoever owns this domain name" — it makes no claim about whether that owner is trustworthy. Conflating the padlock with "safe" is a common security misconception worth calling out.

Middle Questions

Q6: Walk me through the TLS 1.2 handshake.

TLS 1.2 with ephemeral Diffie-Hellman takes two round trips before application data flows:

  1. ClientHello: client sends supported TLS versions, cipher suites, a random nonce, and extensions (including SNI).
  2. ServerHello + Certificate + ServerKeyExchange: server picks a version and cipher, sends its random nonce, its certificate chain, and its DH key-exchange parameters signed with its certificate key. It finishes with ServerHelloDone.
  3. ClientKeyExchange: client sends its DH parameters. Both sides now compute the same pre-master secret and derive session keys.
  4. ChangeCipherSpec + Finished: both sides switch to the negotiated keys and send a Finished message (a MAC over the whole handshake) to prove nothing was tampered with.

That is 2-RTT. Application data starts only after the fourth flight. The extra round trip versus 1.3 is the main latency cost TLS 1.3 removes.

Q7: How does the TLS 1.3 handshake differ, and why is it faster?

TLS 1.3 collapses the handshake to a single round trip by making the client speculate. Since 1.3 only supports (EC)DHE key exchange, the client can guess the group and send its key share immediately in the ClientHello.

sequenceDiagram participant C as Client participant S as Server Note over C,S: TLS 1.3 — 1-RTT C->>S: ClientHello + key_share + SNI + cipher list Note over S: picks cipher, computes shared secret S->>C: ServerHello + key_share S->>C: {EncryptedExtensions, Certificate, CertVerify, Finished} Note over C: verifies cert + Finished, derives keys C->>S: {Finished} C->>S: {Application Data}

Everything after ServerHello is already encrypted (shown in braces), including the certificate — improving privacy. Because the key share arrives in the first flight, the server can derive keys and send its certificate in the second flight, and the client can send application data with its own Finished. That is 1-RTT. TLS 1.3 also removed a decade of legacy: static RSA key exchange, RC4, CBC-mode MAC-then-encrypt, and compression are all gone, which is why forward secrecy and AEAD are effectively mandatory.

Q8: What is a Certificate Authority and how does chain validation work?

A CA is an organization the client's trust store already trusts, whose job is to vouch — by signing certificates — that a public key belongs to a given domain. Browsers and OSes ship with a set of trusted root CA certificates.

Validation walks a chain from the server's certificate up to a trusted root:

  1. The server sends its leaf certificate plus any intermediate CA certificates.
  2. The client checks each certificate's signature was produced by the next one up: leaf signed by intermediate, intermediate signed by root.
  3. The client confirms the chain terminates in a root it trusts locally.
  4. It also checks validity dates, that the hostname matches a SAN, that no cert is revoked, and that basic constraints permit CA certs to sign.

Roots are kept offline and rarely used directly; intermediates do the day-to-day signing so a compromised intermediate can be revoked without replacing the root. A common outage cause is a server that forgets to send the intermediate — some clients then can't build the chain.

Q9: What is SNI and what problem does it solve?

Server Name Indication is a ClientHello extension carrying the hostname the client wants to reach. The problem it solves: the TLS handshake happens before any HTTP request, so without SNI the server wouldn't yet know which of the many sites it hosts the client wants — and therefore which certificate to present. One IP address can host thousands of HTTPS sites; SNI is what lets a single server or load balancer select the right certificate per connection.

The privacy wrinkle is that classic SNI is sent in plaintext, so a network observer can see which domain you're visiting even though the rest is encrypted. Encrypted Client Hello (ECH) addresses this by encrypting the SNI, but it depends on the client fetching a public key (typically via DNS) ahead of time and is still rolling out.

Q10: What is forward secrecy and why does it matter?

Forward secrecy (more precisely perfect forward secrecy) means that compromising the server's long-term private key in the future does not let an attacker decrypt past recorded sessions. Each session's encryption keys are derived from ephemeral key material that is thrown away when the connection ends.

Why it matters: a well-resourced adversary can record encrypted traffic today and store it, betting on stealing the key later — a "harvest now, decrypt later" attack. Without forward secrecy, a single key compromise retroactively exposes every session ever recorded under that key. With forward secrecy, each session must be attacked individually and the ephemeral secrets no longer exist. TLS 1.3 makes forward secrecy mandatory by only allowing ephemeral (EC)DHE key exchange.

Q11: What is an AEAD cipher and why does TLS 1.3 require it?

AEAD stands for Authenticated Encryption with Associated Data. It combines encryption and integrity in a single primitive: it produces ciphertext plus an authentication tag, and decryption fails atomically if either the ciphertext or the associated data was modified. AES-GCM and ChaCha20-Poly1305 are the AEAD ciphers TLS 1.3 uses.

TLS 1.3 requires AEAD because the older "MAC-then-encrypt" and "encrypt-then-MAC" CBC constructions were a rich source of vulnerabilities — padding-oracle attacks like Lucky 13 and POODLE exploited the seam between the encryption and MAC steps and the handling of padding. AEAD removes that seam: there is no separate padding or MAC step to get wrong, and the "associated data" (record headers, sequence numbers) is authenticated too, preventing an attacker from reordering or replaying records.

Senior Questions

Q12: How does session resumption work, and what is the risk of 0-RTT?

Session resumption avoids repeating the full handshake for a client that has connected before. In TLS 1.3 the server issues a session ticket (a pre-shared key, PSK) after the first handshake. On reconnect, the client presents the ticket and both sides resume with a lighter 1-RTT handshake — no certificate exchange needed.

0-RTT goes further: the client sends application data in its first flight, encrypted with a key derived from the resumption secret, before the server has responded. This saves a full round trip and is great for latency.

The risk is replay. Because 0-RTT data isn't tied to a fresh server nonce, an attacker who captures the encrypted early-data packet can resend it, and the server may process it again. So 0-RTT must only carry idempotent, side-effect-free requests — a GET of a cacheable resource is fine; a POST /transfer-money is not. Mitigations include single-use ticket tracking and having the server strip or reject non-idempotent early data. The practical rule: never let 0-RTT reach a non-idempotent endpoint.

Q13: Where should TLS be terminated in a distributed system?

"Termination" means where the TLS session ends and plaintext begins. The common choices, from outside in:

Placement Pros Cons
CDN / edge Offloads handshake cost near the user; DDoS scrubbing; shared cert management Provider sees plaintext; adds a trust dependency
Load balancer Central cert management; cheap backend fan-out; can inspect/route on HTTP Traffic behind the LB is plaintext unless re-encrypted
Reverse proxy / sidecar (per host) Plaintext travels only over loopback; keys isolated per host More certs to manage; more moving parts
Application process True end-to-end; app owns keys Highest CPU cost on app; hardest cert rotation

The senior answer is that it's a layered decision, not one point. A typical pattern is terminate at the edge/LB for the public handshake, then re-encrypt internally (LB-to-service TLS or mTLS) so plaintext never crosses the network unprotected. Terminating at the edge for performance while leaving the internal hop in cleartext is the classic mistake — it trades external security for an internal soft underbelly.

Q14: What is mTLS and when would you use it?

Mutual TLS means both sides present certificates: the server authenticates to the client as usual, and the client also presents a certificate that the server validates. Normal TLS authenticates only the server; mTLS adds strong cryptographic client identity.

When to use it:

  • Service-to-service auth inside a microservice mesh — each service has an identity cert, so a service can cryptographically verify which peer is calling it, independent of network location. This is the backbone of zero-trust networking.
  • High-value API access where API keys aren't strong enough — banking partners, IoT device fleets.
  • Machine identity where you want to bind authorization to a workload rather than a shared secret.

The cost is certificate lifecycle at scale: every workload needs a cert, and short-lived certs must be issued and rotated automatically. This is why service meshes (Istio, Linkerd) bundle an identity CA (often SPIFFE/SPIRE) that mints and rotates workload certs transparently. mTLS is rarely used for browser-facing traffic because provisioning client certs to end users is operationally painful.

Q15: How does certificate revocation work, and why is OCSP stapling preferred?

Revocation is how a CA declares a certificate untrustworthy before its expiry — e.g. after a key compromise. Two classic mechanisms:

  • CRL (Certificate Revocation List): the CA publishes a signed list of revoked serial numbers. These lists grow large and are fetched infrequently, so they're slow to reflect reality.
  • OCSP (Online Certificate Status Protocol): the client asks the CA's responder "is this specific cert still valid?" in real time. But this leaks the user's browsing to the CA, adds latency, and — worst of all — most clients soft-fail: if the responder is unreachable, they proceed anyway, which defeats the purpose.

OCSP stapling fixes this: the server periodically fetches a signed, timestamped OCSP response from the CA and "staples" it into the TLS handshake. The client gets fresh revocation proof with zero extra round trips and zero privacy leak to the CA. Combined with the Must-Staple certificate extension — which tells clients to hard-fail if no stapled response is present — you finally get revocation that actually enforces. The broader industry trend, though, is toward very short-lived certificates so revocation matters less.

Q16: Why does ephemeral Diffie-Hellman give forward secrecy but static RSA key exchange does not?

The difference is which key protects the session secret.

With static RSA key exchange (TLS 1.2 and earlier), the client generates the pre-master secret and encrypts it with the server's long-term RSA public key from its certificate. Anyone who later obtains the server's private key can decrypt any recorded handshake, recover the pre-master secret, and derive the session keys — for every session ever. There is no forward secrecy.

With ephemeral (EC)DHE, both sides generate a fresh, random DH key pair for that connection, exchange public shares, and each computes the shared secret. The long-term certificate key is used only to sign the ephemeral parameters (proving identity), never to encrypt the secret. The ephemeral private keys are discarded when the handshake ends. So even if the certificate's private key is stolen later, it was never able to decrypt the session — the secrets it would need no longer exist. That decoupling of "identity key" from "confidentiality key" is exactly what forward secrecy requires, and why TLS 1.3 dropped static RSA entirely.

Professional / Deep-Dive Questions

Q17: How does TLS defend against a man-in-the-middle attacker?

Consider an attacker who fully controls the network path and can intercept, modify, and inject packets. TLS defends on three fronts:

  1. Authentication defeats impersonation. The attacker can present a certificate, but it must be signed by a trusted CA and valid for the requested hostname. The attacker doesn't have a CA-signed cert for the victim's domain (assuming CAs behave), so certificate validation fails and the client aborts. This is the crux — encryption alone would let the client happily establish a secure channel with the attacker.
  2. The signed handshake defeats parameter tampering. In TLS 1.3 the server signs the handshake transcript (CertificateVerify), and both sides exchange Finished MACs over the full transcript. If the attacker altered the ClientHello (e.g. a downgrade attempt stripping strong ciphers), the Finished check fails.
  3. AEAD defeats record tampering. Once keys are set, every record is authenticated; flipped or injected bytes are rejected.

The residual risks live outside the protocol: a compromised or coerced CA issuing a fraudulent cert (mitigated by Certificate Transparency logs and CAA records), a client that ignores validation errors, or malware installing a rogue root CA on the device.

Q18: Explain the TLS 1.3 key schedule at a high level.

TLS 1.3 derives all keys through a chain of HKDF (HMAC-based key derivation) steps, so that distinct keys protect distinct phases and no key is reused across contexts. The stages:

  • Early Secret — derived from a PSK (or zeros if none). Used for 0-RTT early-data keys.
  • Handshake Secret — derived by mixing the Early Secret with the (EC)DHE shared secret. From it come the handshake traffic keys, which encrypt everything after ServerHello (certificate, CertVerify, Finished).
  • Master Secret — derived from the Handshake Secret. From it come the application traffic keys that protect actual HTTP data, plus the resumption secret used to mint future session tickets.

Each stage feeds the previous secret plus a transcript hash into HKDF-Extract/Expand, so keys are cryptographically bound to the exact handshake messages seen. This design gives forward secrecy (the ephemeral secret is central), enables early separation of handshake vs application keys, and supports key updates mid-connection. The elegance is that a single KDF chain produces every key with clean domain separation, replacing TLS 1.2's ad-hoc PRF usage.

Q19: How do you design certificate lifecycle automation to avoid expired-cert outages?

Expired certificates are one of the most common self-inflicted outages, and they're almost entirely preventable with automation. My design:

  1. Automated issuance and renewal. Use ACME (Let's Encrypt, or an internal ACME CA) with a renewal agent (cert-manager in Kubernetes, certbot, or the LB's built-in ACME). Renew at, say, 2/3 of the lifetime so there's ample buffer to retry failures.
  2. Short lifetimes on purpose. Short-lived certs (90 days publicly, hours/days internally) force the automation to be exercised constantly, so a broken renewal path surfaces long before an outage — the opposite of a two-year cert whose renewal muscle has atrophied.
  3. Independent expiry monitoring. Monitor the actual served certificate from outside (probe port 443, read not-after) rather than trusting that the renewal job ran. Alert at 30/14/7 days remaining. The monitor must not share code or credentials with the issuer, or a single bug blinds both.
  4. Inventory. Maintain a discovered inventory of every cert across LBs, CDNs, internal services, and third-party integrations — the surprise expiries are always the cert nobody remembered owning.
  5. Staged rollout and rollback. Deploy renewed certs the way you deploy code: canary, verify chain completeness, keep the old cert until the new one is confirmed serving.

The governing principle: treat certificates as an automated, monitored pipeline, never as a calendar reminder.

Q20: How would you roll out mTLS across a service mesh without downtime?

The danger is flipping a switch that makes services suddenly require client certs before every caller can present one — instant self-DDoS. The safe path is a permissive-then-strict migration:

  1. Stand up identity infrastructure first. Deploy the workload CA (e.g. SPIRE) and get every workload minting and rotating certs, but don't enforce anything yet.
  2. Enable permissive mode. Services accept both mTLS and plaintext connections. Callers gradually start presenting certs; nothing breaks if they don't yet.
  3. Observe. Use mesh telemetry to confirm what fraction of traffic per service is already mTLS. Chase down the plaintext stragglers — often batch jobs, legacy clients, or health checks.
  4. Flip to strict per service. Once a service sees ~100% mTLS traffic, switch that service to strict mode (reject plaintext). Do it service by service, not fleet-wide, so blast radius is one service.
  5. Automate rotation and keep an escape hatch. Certs must be short-lived and auto-rotated; keep a documented way to drop a service back to permissive if something regresses.

The whole strategy hinges on the mesh's ability to run both modes simultaneously during the transition — that's what makes it zero-downtime.

Staff / Judgment Questions

Q21: How do you deprecate TLS 1.0/1.1 for a large user base?

This is a classic security-versus-availability trade-off, and the answer is data-driven and staged, not a hard cutover.

First, quantify the impact. Instrument the TLS terminator to log negotiated protocol version per connection. Break it down by user segment, geography, device, and — critically — by revenue and business-critical integrations. The 0.3% of users on TLS 1.0 might be an obsolete but high-value B2B partner or a fleet of medical devices, not just old browsers.

Then stage it:

  1. Communicate deadlines to affected partners and publish browser-requirement notices well ahead.
  2. Warn in-band where possible (a banner for old-TLS clients).
  3. Brownout tests — briefly disable old versions during low-traffic windows and measure the real error rate, then re-enable. This turns speculation into measured impact.
  4. Disable by segment — internal/admin traffic first, then progressively wider, keeping a rollback lever.

The judgment is balancing a real security liability (old versions enable downgrade and known attacks, and often fail compliance like PCI-DSS) against cutting off paying users. You lean on the data and give stakeholders a firm date with evidence, rather than either dragging forever or breaking users blindly.

Q22: Would you terminate TLS at the edge or carry it end-to-end to the pod?

There's no universal answer — it depends on the threat model and the sensitivity of the data. I'd reason about it explicitly:

  • Terminate at the edge/LB when performance and operational simplicity dominate, the internal network is well-controlled, and I re-encrypt on the internal hop. The edge can do HTTP-aware routing, WAF, caching, and DDoS absorption — all of which require plaintext. This covers most web workloads.
  • Carry TLS/mTLS to the pod when I'm operating a zero-trust posture, handling regulated data (PCI, HIPAA, PII), running in a shared or untrusted network, or need cryptographic service identity for authorization. Here "the network is a boundary I don't trust" is a first-class assumption.

The nuance I'd voice: it's rarely edge or pod — it's usually edge termination for the public handshake plus internal mTLS between services, so you get edge features and end-to-end confidentiality. The anti-pattern is terminating at the edge and then sending plaintext across a data-center network you've quietly decided to trust, because lateral movement after a single breached host is exactly how internal cleartext gets exploited. So my default is: terminate where you need L7 features, but never let plaintext cross a network segment — re-encrypt every hop.

Q23: A cert expired in production and took the site down. How do you respond and prevent recurrence?

Two phases: stop the bleeding, then make it structurally impossible.

Incident response:

  1. Confirm root cause fast — probe the served cert's not-after; an expired leaf shows as handshake failures across all clients simultaneously, which is a distinctive signature.
  2. Issue and deploy a fresh cert immediately. If ACME issuance is slow or rate-limited, have a break-glass path (a pre-staged cert, or a fallback CA).
  3. Verify the full chain is served, not just the leaf — a common follow-on mistake is deploying a valid leaf but forgetting the intermediate.
  4. Communicate status; the outage is total, so treat it as a Sev-1.

Prevention (the real work, in the postmortem):

  • Add external expiry monitoring that reads the actually-served cert and alerts weeks out — decoupled from the renewal system so one bug can't blind both.
  • Move to automated ACME renewal and short-lived certs so the renewal path is exercised continuously.
  • Build a cert inventory so no cert is un-owned.
  • Ask the deeper question: why did a known future event with a known date cause an unplanned outage? That's a process failure, not bad luck. The fix is making renewal an automated, monitored pipeline rather than relying on human vigilance.

Q24: When is it acceptable to pin certificates, and what are the risks?

Certificate (or public-key) pinning means the client hard-codes which certificate or key it will accept for a host, refusing anything else even if it's CA-valid. It defends against a fraudulently-issued-but-CA-valid cert — a rogue or compromised CA.

When it's justified:

  • Mobile apps talking to their own backend, where you control both ends and can ship updates — pinning to your own key protects users even if a CA is compromised or a device has a rogue root installed.
  • High-assurance machine-to-machine links with a stable, controlled endpoint.

The risks — and why I'm cautious:

  • Bricking. If you rotate to a key you didn't pre-pin, every pinned client is locked out until they update. This has caused real, hard-to-recover outages. HTTP Public Key Pinning (HPKP) for browsers was deprecated precisely because sites pinned themselves off the internet.
  • Operational rigidity. Pinning fights certificate automation and short lifetimes — the very practices we otherwise want.

So my rule: pin only where you fully control the client and can guarantee updates, always pin a backup key you haven't deployed yet, pin the public key rather than the leaf cert (so you can reissue certs freely), and keep an emergency unpin path. For general web traffic, prefer CAA records and Certificate Transparency monitoring over pinning — you get much of the protection without the self-inflicted-outage risk.

Next step: HTTP Evolution