Knowledge Base


Knowledge BaseCertificates
64-Character Limitation on Common Name (CN) Field in X.509 Certificates
Updated on September 30, 2024
There is a 64-character limitation on the Common Name (CN) field in X.509 certificates, which is derived from the ITU-T X.520 standard. This standard defines the attributes used in X.509 certificates, including the Common Name attribute, and specifies a maximum length of 64 characters for the CN field.
Standards and Implementation
While the ITU-T X.520 standard itself isn't freely accessible, this limitation is reflected in various industry standards and implementations:
Here are some other sources that confirm the 64-character limitation for the Common Name (CN) field:
Practical Implications
The 64-character limit has several practical implications:
Given the evolving standards and the need for compatibility across various systems:
Standards and Implementation
While the ITU-T X.520 standard itself isn't freely accessible, this limitation is reflected in various industry standards and implementations:
- ITU-T X.520 Standard: The Common Name attribute is defined with a maximum size of 64 characters. This constraint is enforced by certificate authorities and various tools, even though the standard itself is not freely available.
- RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile:
RFC 5280 profiles the X.509 v3 certificate and v2 CRL for use on the Internet and incorporates the limitations of the X.520 standard, including the restriction that the Common Name field should not exceed 64 characters.- Section 4.1.2.4 of RFC 5280 discusses the subject field, which includes the Common Name (CN) attribute.
- Link to RFC 5280 - Section 4.1.2.4
- https://datatracker.ietf.org/doc/html/rfc5280
- CA/Browser Forum Baseline Requirements:
Certificate Authorities (CAs) comply with the Baseline Requirements set by the CA/Browser Forum, which enforce adherence to RFC 5280 and other related standards like X.520.- Link to CA/Browser Forum Baseline Requirements, Section 7.1.4.2.2, Page 108
- https://cabforum.org/uploads/CA-Browser-Forum-TLS-BRs-v2.0.2.pdf
Here are some other sources that confirm the 64-character limitation for the Common Name (CN) field:
- Let’s Encrypt Community: Discussion on a 63-Character Domain Certificate
- https://community.letsencrypt.org/t/a-certificate-for-a-63-character-domain/78870
- DigiCert Documentation:
DigiCert’s official documentation explicitly states: "We cannot allow the common name value to exceed the 64-character limit."
https://docs.digicert.com/en/certcentral/manage-certificates/public-certificates---data-entries-that-violate-industry-standards.html
Practical Implications
The 64-character limit has several practical implications:
- Certificate Generation: Most certificate generation tools and CAs enforce the 64-character limit, rejecting requests with CNs that exceed this size.
- Client Compatibility: Even if a certificate with a longer CN is generated, many clients and systems might reject it due to compatibility issues.
- Subject Alternative Name (SAN) Extension:
- It is recommended to use the SAN extension instead of or in addition to the CN field. SANs allow for multiple domain names and are not restricted by the CN character length.
- Omitting CN:
- Modern practices often involve placing all domain names in the SAN extension and leaving the CN field empty or unused. This method avoids issues with CN length and remains compliant with current standards.
- Wildcard Certificates:
- For very long hostnames, wildcard certificates (e.g., *.example.com) can be a practical solution.
- Client Compatibility: While using only SANs is becoming standard, some older clients may still require a CN for compatibility. Including both CN and SAN ensures broader support across systems.
- CA/Browser Forum Guidelines: The Baseline Requirements from the CA/Browser Forum emphasize that if a SAN extension is present, it should be used for identity verification rather than the CN field.
- Future Trends: Browser vendors like Google Chrome plan to discontinue support for CN matching in certificates, shifting entirely to SAN-based identity validation.
Given the evolving standards and the need for compatibility across various systems:
- Use the SAN extension: Ensure all necessary domain names are included in the SAN extension.
- Shortened CN: If possible, include a shortened version of the primary domain in the CN field for backward compatibility.
- Consider omitting the CN: If CN length becomes problematic, omit it entirely and rely solely on SANs. This approach is becoming increasingly standard.
Need help?
Need help making a purchase? Contact us today to get your certificate issued right away.
Live chat
Click the button below or click "Chat with an Expert" to start chatting with us now!