Why Subject Alternative Names (SANs) Matter for Modern Browsers

The single most common reason self-signed certs stop working in browsers — and the fix.

For two decades, SSL/TLS certificates identified themselves via the Common Name (CN) field in the Subject Distinguished Name. Today, browsers ignore it completely. If your certificate doesn't have a Subject Alternative Name (SAN) matching the hostname, every modern browser will reject it — even if the CN is exactly right.

The short version

When you visit https://example.com, the browser checks the server's certificate for a SAN entry containing example.com. If no SAN matches, the connection is rejected with an error like NET::ERR_CERT_COMMON_NAME_INVALID. The Common Name is not consulted.

When did this change?

2000: RFC 2818 says "if a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used."
2012: CA/Browser Forum Baseline Requirements mandate SANs for CA-issued certs.
2017 (Chrome 58): Chrome removes the CN fallback. Firefox follows shortly after. Safari had never accepted CN-only certs.
Today: Every major browser ignores CN.

What a SAN looks like

The SAN is an X.509 extension. In a certificate, it might look like:

X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:*.dev.example.com
    IP:127.0.0.1
    IP:192.168.1.1

Paste any certificate into our PEM decoder to see its SAN entries.

Generating a cert with SANs

With cert-depot.com: just list each SAN on its own line in the SANs field. The CN is automatically included as a SAN; you only need to list additional names (other domains, wildcards, IPs).

With OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout key.pem -out cert.pem -days 365 \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:127.0.0.1"

The -addext flag was added in OpenSSL 1.1.1 (2018). On older versions, you need a config file.

Types of SAN you can include

dNSName — a domain like example.com or wildcard *.example.com. Wildcards match exactly one label.
iPAddress — a literal IPv4 or IPv6 address. Useful for direct-to-IP testing.
uniformResourceIdentifier — a URI. Used for OCSP responder URLs, not hostname matching.
rfc822Name — an email address. Used for S/MIME, not TLS.

Wildcard rules

A wildcard like *.example.com matches foo.example.com but not:

example.com itself (the apex)
foo.bar.example.com (deeper subdomains)

Practical implication: include both example.com and *.example.com as separate SAN entries to cover both cases.

Can the CN still be set?

Yes — and it's often set to the primary domain for readability in cert listings. But browsers ignore it. Set it to whatever the primary name is, and make sure that same name is in the SAN list.

Need a self-signed certificate? Use our free generator — browser-compatible SANs, RSA or ECDSA, ZIP or PFX. No signup, no ads, keys never stored.

Certificate Depot