Subject Alternative Name (SAN) Certificates: A Complete SSL/TLS Guide

How Certificates Work

A TLS certificate is an X.509 document that binds a public key to a domain name. When a browser connects, the server presents its certificate. The browser verifies three things: the certificate is signed by a trusted Certificate Authority (CA), the domain in the certificate matches the domain in the URL, and the certificate has not expired.

If any check fails, the browser shows a warning page. Most users will not click through it. Google also uses HTTPS as a ranking signal — sites without valid TLS rank lower. The certificate chain works like this: your cert is signed by an intermediate CA, which is signed by a root CA that ships with the operating system. The browser walks the chain up to a trusted root. If any link is missing or broken, validation fails.

For the full TLS picture including handshake mechanics and cipher suites, see our Complete Guide to Web Security.

DV, OV, and EV Certificates

Browsers stopped showing the green address bar for EV certs in 2019. From a user perspective, DV and EV look identical. Pick DV unless an auditor or compliance framework specifically requires OV or EV. Wildcard certs (*.example.com) are available at all validation levels and cover all subdomains one level deep.

Let's Encrypt Setup

Let's Encrypt is a free, automated CA that issues DV certificates. It uses the ACME protocol (RFC 8555) for domain validation. The standard client is Certbot:

# Install Certbot (Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx

# Get a certificate and configure Nginx automatically
sudo certbot --nginx -d example.com -d www.example.com

# Test auto-renewal
sudo certbot renew --dry-run

Certificates expire after 90 days by design — short lifetimes limit the damage from key compromise. Certbot sets up a cron job (or systemd timer) for automatic renewal. If you are behind a load balancer or CDN (Cloudflare, Vercel, AWS CloudFront), they handle certificate provisioning for you automatically.

For DNS-based validation (needed for wildcard certs), use the --preferred-challenges dns flag with a DNS plugin for your provider. This proves domain ownership by creating a TXT record rather than serving a file.

Common TLS Errors

• ERR_CERT_DATE_INVALID— Certificate expired. Set up auto-renewal. If already configured, check that the renewal cron job is actually running and has permissions to write to the cert directory.
• ERR_CERT_COMMON_NAME_INVALID— The domain in the URL does not match any Subject Alternative Name (SAN) in the certificate. This happens when you add a subdomain but forget to include it in the cert. Re-issue with all needed domains.
• ERR_CERT_AUTHORITY_INVALID— The browser does not trust the CA. Usually means a self-signed certificate or a missing intermediate certificate. Always serve the full chain: your cert + intermediate(s). The root CA should NOT be included (browsers have it built in).
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH— Server and client cannot agree on a protocol version or cipher suite. Usually means the server only supports TLS 1.0/1.1 (deprecated) or uses ciphers the browser has removed. Upgrade to TLS 1.2+.
• Mixed content warnings— HTTPS page loads HTTP resources. Fix by updating all resource URLs to HTTPS or using the upgrade-insecure-requests CSP directive.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446) is the current standard. Key improvements over TLS 1.2:

• Faster handshake— 1 round-trip instead of 2. Saves 50-100ms per new connection.
• Mandatory forward secrecy— All cipher suites use ephemeral Diffie-Hellman. No RSA key exchange.
• Fewer cipher suites— Only 5 suites, all AEAD. No room for misconfiguration.
• 0-RTT resumption— Returning clients can send data immediately. Caveat: 0-RTT data is vulnerable to replay attacks. Only enable for idempotent requests.
• Encrypted handshake— The server certificate is encrypted during the handshake, preventing passive observers from seeing which site you connect to.

To check your server's TLS configuration, run openssl s_client -connect example.com:443 -tls1_3. If it connects, TLS 1.3 is supported. Disable TLS 1.0 and 1.1 entirely — they were deprecated in RFC 8996.

HSTS Preload

HSTS (RFC 6797) tells browsers to always use HTTPS for your domain. But there is a catch: the browser has to see the header at least once. On the very first visit, the user might still connect over HTTP. HSTS preload fixes this by hardcoding your domain into the browser itself.

Requirements for preload submission:

1. Serve a valid certificate on the bare domain (not just www)
2. Redirect HTTP to HTTPS on the same host before redirecting to www (if applicable)
3. Serve the HSTS header on the base domain with max-age of at least 31536000 (1 year), includeSubDomains, and preload

Submit at hstspreload.org. Be careful: removal from the preload list takes months. Make sure every subdomain works over HTTPS before submitting.

Test Your TLS

Our scanner checks your TLS version, certificate validity, expiration date, chain completeness, and HSTS configuration. You get a pass/fail for each check with specific fix instructions.

Scan My Website — Free