HTTPS & SSL/TLS Certificates Basics

Hypertext Transfer Protocol Secure (HTTPS) is not a separate protocol from HTTP. Instead, it is the secure version of HTTP, where ordinary HTTP transactions are layered over a secure Transport Layer Security (TLS) session.

In a traditional web request, your browser speaks plain HTTP directly over a raw TCP connection. With HTTPS, the browser first establishes a TCP connection, performs a TLS handshake to secure the channel, and then transmits HTTP request and response payloads encrypted through that channel.

Real-World Analogy

Think of plain HTTP as writing a letter on a postcard. Anyone who handles the postcard, from your local mail carrier to sorting facilities, can read your message (e.g. login credentials) or even scribble over it to modify the text. HTTPS is like placing the letter in an armored lockbox before mailing it. The lockbox is secure, but you also need a trusted way to verify that the person handing you the lockbox is actually who they claim to be. That is where digital certificates act as official, tamper-proof ID badges.

---

Operating a website or API over plain HTTP exposes users and servers to significant security risks, primarily through two types of active and passive network attacks:

• Packet Sniffing: Attackers on the same network (like a public Wi-Fi hotspot) use network analyzers to capture raw IP packets. Because HTTP transmits headers and bodies in clear text, attackers can easily extract sensitive credentials, session tokens, and personal data.
• Packet Injection: Middleboxes, internet service providers, or malicious actors can intercept HTTP packets in transit and alter their payloads. This allows them to inject unwanted advertisements, track scripts, or malicious code directly into the web pages served to clients.

By encrypting the entire application payload, HTTPS ensures confidentiality (preventing sniffing) and integrity (preventing injection or tampering).

---

To prove their identity, web servers present digital certificates formatted according to the X.509 standard. An X.509 certificate acts as a public ledger binding a public key to an identity (such as a domain name).

An X.509 certificate contains several structured fields:

• Subject Name: The entity to which the certificate is issued, typically identified by a Common Name (CN) or listed inside the Subject Alternative Name (SAN) field for domain names.
• Issuer: The Certificate Authority (CA) that validated the entity and generated the certificate signature.
• Validity Period: The time window, marked by Not Before and NotAfter timestamps, during which the certificate is cryptographically valid.
• Public Key: The cryptographic public key belonging to the server, used by clients during the TLS handshake to encrypt session information or verify signatures.
• CA Digital Signature: A hash of the certificate's fields, encrypted using the CA's private key. This ensures the certificate fields cannot be altered without breaking the signature.

---

When a browser connects to an HTTPS server, it receives the server's certificate along with a chain of intermediate certificates. The browser must cryptographically verify that the certificate is authentic by tracing it back to a trusted source.

This verification walks up a Chain of Trust:

The client browser validates the certificate using these sequential steps:

1. Extract and Parse: The browser extracts the server's domain certificate. It checks that the domain example.com matches the certificate Subject Name or SAN.
2. Verify Signature: The browser uses the public key of the issuer (the Intermediate CA, Let's Encrypt R3) to cryptographically verify the Domain Certificate's signature.
3. Walk Up the Chain: The browser then verifies the Intermediate CA certificate signature using the public key of the Root CA (ISRG Root X1).
4. Anchor to Root Store: The chain must end at a Root CA certificate that is stored locally in the client's operating system or browser Root Store. Because the root store contains certificates hardcoded by the software vendor, matching the signature against a local root certificate establishes ultimate trust.

If any signature verification fails, or if a certificate in the chain has expired, the browser aborts the TLS handshake and displays a security warning.

---

Certificate Authorities issue certificates with different validation scopes, reflecting the depth of background checking performed:

• Domain Validation (DV): The CA verifies only that the applicant controls the target domain name (e.g. via DNS records). DV certificates are cheap, can be issued instantly, and are ideal for standard web encryption.
• Organization Validation (OV): The CA verifies domain control and performs a basic check of the applicant organization's legal existence. The organization's name is embedded in the certificate.
• Extended Validation (EV): The CA conducts a rigorous audit of the organization's legal registration, physical address, and operational status. Historically, browsers displayed a green address bar for EV certificates, though modern browsers have phased this indicator out.

Note: All three scopes offer identical cryptographic strength; they differ only in the level of identity assurance provided.

---

Managing certificates involves several operational steps to ensure continuous uptime and security:

• Generating Private Keys: Administrators generate a private key (using RSA or ECDSA) that must remain secure on the application server. The public key is derived from this private key.
• Creating a Certificate Signing Request (CSR): A CSR is a structured file containing the server's public key, domain names, and organization details. This request is sent to the CA for signing.
• Tracking Expirations: Certificates have strict validity windows. If a certificate expires before renewal, browsers will immediately block client traffic. Operating systems and APIs must monitor certificate lifespans to trigger renewals proactively.

---

Historically, requesting certificates was a manual process involving high costs and yearly administration. The Automated Certificate Management Environment (ACME) protocol, created by Let's Encrypt, automated this entire lifecycle.

The ACME client on the web server requests a certificate, and the CA issues a challenge to prove domain ownership:

• HTTP-01 Challenge: The CA requests the ACME client to place a specific token file at a designated path on the web server (e.g. http://example.com/.well-known/acme-challenge/token). The CA then fetches this path over plain HTTP to verify control.
• DNS-01 Challenge: The CA requests the ACME client to create a specific DNS TXT record (e.g. _acme-challenge.example.com). The CA queries the public DNS system to verify the record, which is useful for obtaining wildcard certificates where HTTP verification is impractical.

Once verified, the CA automatically issues the certificate. Because ACME certificates have short lifespans (typically 90 days), automated clients renew them every 60 days, eliminating manual overhead.

---

• RFC 5280: Internet X.509 Public Key Infrastructure Profile — The official IETF specification defining X.509 certificate fields and trust path validation.
• RFC 8555: Automated Certificate Management Environment (ACME) — Detailed protocol specification detailing DNS-01 and HTTP-01 challenges.
• Let's Encrypt Documentation — Practical guides explaining how the ACME protocol works under the hood.
• Mozilla Root Store Policy — Requirements and evaluation procedures for Root CAs included in client root stores.