The 64 Character Limit on the Common Name Field

The 64 Character Limit on the Common Name Field

Andrew Johnson

Long hostnames run into a wall that surprises everyone the first time. The Common Name (CN) field of an SSL Certificate accepts a maximum of 64 characters, a structural limit inherited from the X.509 standard itself, and a Fully Qualified Domain Name (FQDN) one character over it cannot be placed there at all.

The good news is that the limit stopped mattering for trust years ago, and a longer hostname secures perfectly well through a different field.

Where the Limit Bites

The failure usually appears at Certificate Signing Request (CSR) generation, with OpenSSL refusing the subject as too long, or a control panel rejecting the hostname field. Deeply nested subdomains are the usual culprits, the kind produced by cloud platforms, regional naming schemes, and machine generated environments.

Counting includes every character of the full hostname, dots included, so a name that looks borderline often measures over.

The Limit Stopped Mattering for Trust

Browsers stopped reading the Common Name (CN) for hostname matching long ago. The Subject Alternative Name (SAN) entries are the authoritative list of what an SSL Certificate covers, every modern client validates exclusively against them, and SAN entries accommodate hostnames up to the full length the Domain Name System (DNS) itself allows.

A hostname too long for the Common Name (CN) therefore secures exactly as well as a short one, provided it appears as a SAN entry, which is where coverage genuinely lives. Learn About Understanding SAN Certificates 🔗

Ordering for a Long Hostname

The practical approach places a shorter name in the Common Name (CN) and the long hostname among the SAN entries. The parent domain or a shorter sibling hostname both work well as the subject, keeping Certificate Signing Request (CSR) generation happy while the SAN list carries the names that matter.

A Multi-Domain SSL Certificate is the natural fit when several long hostnames need coverage together, since its entire design revolves around the SAN list. Learn About Multi-Domain SSL Certificates 🔗

Tip : A Wildcard SSL Certificate sidesteps the question entirely for deep single-level subdomains, covering every name at that level regardless of length, which often suits the machine generated naming schemes that trigger the limit in the first place.

Whichever shape the order takes, generation follows the same pattern.

Generating the Request

Generate the Certificate Signing Request (CSR) with the shorter subject and supply the long hostname during ordering, where it joins the SAN list. Platform guides for generation are collected in one place. Learn About Generating a CSR 🔗

The issued SSL Certificate then lists every covered name in its SAN entries, the long hostname validates and serves normally, and the 64 character ceiling never enters the picture again.

A Related Pitfall Worth Knowing

Errors naming the Common Name (CN) usually trace to coverage rather than length, with clients connecting to a hostname the SSL Certificate simply does not list. The two problems look similar from the browser and resolve very differently. Learn About SSL Common Name Mismatch Explained 🔗

Back to Blog

Most Popular Questions

Frequently asked questions covering the 64 character limit on the Common Name (CN) field, including the X.509 structural origin, where the limit appears, the Subject Alternative Name (SAN) entries that made it irrelevant for trust, ordering patterns, Wildcard coverage, and coverage errors mistaken for length problems.

The Structural Limit from the X.509 Standard

The Common Name (CN) field of an SSL Certificate accepts a maximum of 64 characters, a structural limit inherited from the X.509 standard itself, and a Fully Qualified Domain Name (FQDN) one character over it cannot be placed there at all. Counting includes every character of the full hostname, dots included, so a name that looks borderline often measures over.

The First Place the Limit Appears

The failure usually appears at Certificate Signing Request (CSR) generation, with OpenSSL refusing the subject as too long or a control panel rejecting the hostname field. Deeply nested subdomains are the usual culprits, the kind produced by cloud platforms, regional naming schemes, and machine generated environments.

The SAN Entries That Made the Limit Irrelevant

Browsers stopped reading the Common Name (CN) for hostname matching long ago, and the Subject Alternative Name (SAN) entries are the authoritative list of what an SSL Certificate covers, with every modern client validating exclusively against them. SAN entries accommodate hostnames up to the full length the Domain Name System (DNS) itself allows, so a hostname too long for the Common Name (CN) secures exactly as well as a short one.

Ordering with a Short Subject and Long SAN Entries

The practical approach places a shorter name in the Common Name (CN), with the parent domain or a shorter sibling hostname both working well, and the long hostname among the Subject Alternative Name (SAN) entries. A Multi-Domain SSL Certificate is the natural fit when several long hostnames need coverage together, since its entire design revolves around the SAN list.

Wildcard Coverage for Machine Generated Names

A Wildcard SSL Certificate sidesteps the question entirely for deep single-level subdomains, covering every name at that level regardless of length. That often suits the machine generated naming schemes that trigger the limit in the first place.

Common Name Errors That Are Really Coverage Problems

Errors naming the Common Name (CN) usually trace to coverage rather than length, with clients connecting to a hostname the SSL Certificate simply does not list. The two problems look similar from the browser and resolve very differently.

Stay Updated - Our RSS Feed

There's never a reason to miss a post! Subscribe to our Atom/RSS feed and get instant notifications when we publish new articles about SSL Certificates, security updates, and news. Use your favorite RSS reader or news aggregator.

Subscribe via RSS/Atom