Handling Multiple CNs on a Single Certificate

Luke Hebert

- 2 minutes read - 333 words

If you are working with a certificate that lists more than one Common Name in the Subject field, you are likely to run into validation failures across browsers, load balancers, and client libraries. The modern approach is to put a single CN in the Subject and list every additional name in the Subject Alternative Name (SAN) extension.

How the CN and SAN Fields Work

The RFCs governing TLS and certificate creation state that the CN field should carry only one name. That name, along with any additional hostnames or FQDNs, belongs in the SAN section. When both are present, the SAN takes precedence over the Subject CN.

In practice:

  • The Subject field holds exactly one CN.
  • The SAN extension lists the CN plus every other name the certificate should protect.
  • More than one CN in the Subject field breaks validation in many client stacks.

What the RFCs Say

RFC 2818 and RFC 6125 are explicit on this point. From RFC 2818:

Note

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. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

A Real-World Example

The Mozilla Bug Tracker entry marked as Invalid is a useful illustration. The comment chain walks through how NSS handled multiple CNs and what “most specific” actually means in the lookup order. Even though NSS is no longer the dominant library, the behavior it describes still reflects how most stacks resolve identity: multiple CN fields will not work the way you would expect.

Key Takeaway

Avoid issuing certificates with multiple CNs in the Subject. Put a single CN there and enumerate every additional name in the SAN extension. This is the path that every major browser, OS, and load balancer validates correctly.

References