SAN vs. Common Name: Which Field Matters for HTTPS?

If you're wondering whether the Subject Alternative Name (SAN) or the Common Name (CN) matters more for HTTPS — the answer is clear: browsers use the SAN, not the CN, for hostname validation. The CN is effectively ignored for TLS hostname matching in all modern browsers.

The Historical Context

Early TLS (SSL 2.0/3.0 era) certificates only had the CN field. Browsers matched the CN against the URL hostname. When multi-domain and wildcard certificates became common, the SAN extension (already defined in RFC 2459) became the right place to list all covered hostnames.

RFC 2818 (2000) specified that clients should prefer SANs over CN when the SAN extension is present. The CA/Browser Forum eventually required CAs to always include the domain in the SAN, and in 2017 Chrome 58 stopped honoring CN-only certificates entirely.

Current Rules for Browsers

• Chrome (since v58, 2017): Only checks SAN. CN-only → hostname mismatch error.
• Firefox (since v48, 2016): Only checks SAN for new certificates.
• Safari: Only checks SAN.
• Edge: Only checks SAN.

What to Do With This Information

If you're generating certificates (e.g., for internal services or test environments), always include your hostname in the SAN extension, not just the CN. All major ACME clients and CA issuance systems do this automatically for public certificates. If you're using openssl to generate a self-signed certificate for development, use the -addext "subjectAltName=DNS:localhost" option.

How to Verify in the Decoder

Paste your certificate into the decoder and verify that every hostname you need to cover appears in the Subject Alternative Names section. The CN field is informational at this point — if it appears, it should typically match the primary SAN entry, but what matters for browsers is the SAN list.