Knowledge Base

ITU-T X.520 Standard 
Defines the Common Name attribute with a maximum size of 64 characters. Although the standard is not freely accessible, its rules are reflected across industry tools and CA implementations. 

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile 
RFC 5280 profiles the X.509 certificate for use on the internet and incorporates X.520 attribute definitions, including the CN length restriction. 
Relevant section: 4.1.2.4 – Subject Field 
Link: https://datatracker.ietf.org/doc/html/rfc5280 

CA/Browser Forum Baseline Requirements 
CAs must comply with the Baseline Requirements, which enforce adherence to RFC 5280 and related standards. 
Relevant section: 7.1.4.2.2 
Link: https://cabforum.org/uploads/CA-Browser-Forum-TLS-BRs-v2.0.2.pdf 

Let’s Encrypt Community Discussion 
Confirms the 64-character limitation when issuing certificates for long domain names. 
Link: https://community.letsencrypt.org/t/a-certificate-for-a-63-character-domain/78870 

DigiCert Documentation 
Explicitly states: “We cannot allow the common name value to exceed the 64‑character limit.” 
Link: https://docs.digicert.com/en/certcentral/manage-certificates/public-certificates---data-entries-that-violate-industry-standards.html 

Generating X.509 certificates where domain names or identifiers exceed standard lengths. 

Ensuring compatibility across legacy and modern systems that validate CN fields. 

Designing certificate issuance processes for complex or long hostnames (e.g., deeply nested subdomains). 

Certificate Generation: 
Most certificate-generation systems reject CSRs with CN values for longer than 64 characters. 

Client Compatibility: 
Even if a certificate with a longer CN is created, many systems—including browsers and enterprise clients—may reject it. 

Recommended modern approach. 

Allows multiple DNS names. 

Not bound by the 64-character CN limit. 

Increasingly common practice. 

All hostnames are supplied via SANs. 

Avoids CN length issues and remains at standards compliant. 

Useful when dealing with domains that have extremely long subdomains. 
(e.g., *.example.com instead of a long fully qualified hostname) 

Legacy Compatibility: 
Some older systems still rely on CN matching. Including both CN and SAN ensures maximum compatibility. 

CA/Browser Forum Guidance: 
Modern validation is moving toward SAN-only checks. CN usage is being deprecated. 

Future Trends: 
Browser vendors (e.g., Google Chrome) plan to remove CN matching entirely, making SAN the authoritative field for domain identity. 

Use the SAN extension for all domain identities. 

Include a shortened CN when backward compatibility is required. 

Omit the CN entirely if its length is problematic and your systems support SAN-only validation. 

Test across all target systems to ensure the certificate is accepted and behaves as expected.