SSL/TLS Certificate

SSL/TLS Certificate is an X.509 digital certificate that a certificate authority (CA) issues to authenticate a domain owner and provide the public key used in the TLS handshake to establish encrypted HTTPS connections. Despite the name, modern certificates use TLS (Transport Layer Security) rather than the deprecated SSL (Secure Sockets Layer) protocol. Without a valid certificate, browsers display security warnings and many HTTP/2 clients refuse to connect. In self-hosted setups, certificates are typically provisioned automatically via the ACME protocol from Let’s Encrypt.

How it works

During a TLS handshake, the server presents its certificate to the client. The client verifies the certificate is signed by a trusted CA (from the OS or browser trust store), that the certificate’s Subject Alternative Name (SAN) matches the hostname being connected to, and that the certificate has not expired. If all checks pass, the client uses the certificate’s public key to negotiate a shared session key (via Diffie-Hellman key exchange in modern TLS), and subsequent communication is encrypted with that session key. Certificate validity periods are typically 90 days for Let’s Encrypt or 1 to 2 years for commercial CAs.

Key facts

• DV vs. OV vs. EV: Domain Validation (DV) certificates verify domain ownership only and are what Let’s Encrypt issues; OV and EV certificates additionally validate organizational identity
• Wildcard certificates: A wildcard cert (*.example.com) covers all subdomains with a single certificate; Let’s Encrypt issues wildcards but requires DNS-01 challenge validation
• Certificate Transparency: All publicly trusted certificates must be logged to CT logs, making it possible to audit all certificates issued for a domain via crt.sh

For builders

Self-hosters using a reverse proxy with Caddy or Traefik typically never need to think about certificates directly, since these tools automate ACME provisioning and renewal. The edge cases where manual certificate management becomes necessary include wildcard certificates for dynamic subdomain routing, internal services not exposed to the internet (which require DNS-01 ACME challenges or a private CA), and situations where certificate pinning in mobile apps requires a specific CA.

Sources

• IETF. RFC 8555: Automatic Certificate Management Environment (ACME). datatracker.ietf.org
• IETF. RFC 8446: TLS 1.3. datatracker.ietf.org
• Internet Security Research Group. Let’s Encrypt documentation. letsencrypt.org
• NIST SP 800-52 Rev. 2. Guidelines for the Selection, Configuration, and Use of TLS Implementations. nist.gov
• CISA. Cybersecurity advisories and guidance. cisa.gov