Automatic HTTPS in practice, and wildcard certificates

Every platform this subcategory has covered — Vercel, Railway, Render — issues certificates automatically via Let's Encrypt, using the ACME (Automated Certificate Management Environment) protocol: the platform proves to Let's Encrypt's servers that it actually controls the domain (usually by serving a specific file at a specific path, or via a DNS TXT record), and Let's Encrypt issues a certificate in response — entirely automated, with no human ever manually requesting or downloading anything. This is the concrete machinery behind every "automatic HTTPS" feature this subcategory's domains have each described from their own platform's specific angle.

Networking Fundamentals' own TLS lesson already named this: certificates expire deliberately, rarely longer than about 13 months, specifically so a compromised or outdated certificate can't stay trusted indefinitely. Automated platforms renew well before expiry, silently, with no action needed — the real risk this protects against is a manually-managed certificate nobody remembered to renew, which is exactly the class of outage this whole automated-ACME approach exists to eliminate for anything running on a modern platform.

A wildcard certificate covers an entire first-level subdomain pattern (*.example.com) in one certificate, rather than needing a separate certificate per subdomain — genuinely useful for a setup with many subdomains (lesson 6's own subdomain-strategy territory), or specifically for multi-tenant products issuing a unique subdomain per customer (customer1.example.com, customer2.example.com), where manually provisioning a separate certificate per tenant would be completely impractical at scale.

A wildcard certificate for *.example.com covers any single additional label before the domain — it does not automatically extend to a second level of nesting. A genuinely deep subdomain structure needs either its own wildcard at that deeper level (*.api.example.com) or its own specific certificate, and assuming one wildcard certificate covers an arbitrarily deep subdomain hierarchy is a real, easy mistake worth naming explicitly.

Networking Fundamentals' own HTTPS lesson already covered the mixed-content problem for a single page loading an HTTP resource — the same concern extends directly across subdomains: a page served from https://example.com loading a script from http://cdn.example.com (even under the same root domain) triggers the identical mixed-content blocking, because HTTPS protection is evaluated per-origin, and a subdomain without its own HTTPS is a genuinely separate, insecure origin regardless of sharing a parent domain.