Restrictions on data entries for public certificates
Baseline requirements and RFC 5280 violations
For publicly trusted certificates, industry standards (baseline requirements and RFC 5280) require data entries to meet certain criteria. Violating these standards when ordering a certificate prevents a Certificate Authority (CA) from issuing the certificate.
Organization unit value violation
Important
DigiCert is deprecating the Organizational Unit (OU) field to simplify public SSL/TLS certificate ordering. For more information about OU field deprecation, see DigiCert will deprecate the Organizational Unit field.
For publicly trusted certificates, the organization unit value is not a required value (field).
According to baseline requirements, Certificate Authorities (CAs) are only required to validate the organization unit value when a value is provided. If you leave this field blank, CAs are instructed not to include the field in the certificate.
Baseline requirements also prohibit this value from being or appearing to be "junk" data or indicators of non-applicability (na, ?, etc.), which keep certificates smaller. By keeping certificates smaller, this ensures TLS remains accessible to a greater range of users and site operators.
The list below contains characters that, if entered by themselves in the organization unit field, do not represent a valid organization unit value:
"-" (Hyphen)
" " (Space)
"." (Period)
"?" (Question mark)
"na" (Not applicable)
"NA" (Not applicable)
Warning
If you put a hyphen by itself in the organization unit field, a CA will be unable to validate the value.
However, if you enter an organization name that includes a hyphen in it (for example, Dev-Ops), a CA will still be able to validate your organization unit value.
64-character maximum limit violation
For publicly trusted certificates, we cannot allow these values (data entries) to exceed the 64-maximum character limit, including spaces:
Common name
We cannot allow the common name value to exceed the 64-character limit. However, the subject alternative names (SANs) value does not have the same character length restrictions as the common name value. The SANs included in a certificate order (for example, in a multi- domain SSL certificate order) can be greater than 64 characters.
Organization
Does the organization include an assumed name? Do you plan to validate that organization for extended validation (EV) certificates? Make sure the organization name + assumed name values do not exceed 64 characters, including spaces.
Street 1
Street 2
City
State
Postal code
Use of underscores violation
For publicly trusted certificates, we no longer allow the use of underscores ( _ ) in:
Subject Common Names
Subject Alternative Names (SANs)
We only issue certificates for domains and subdomains using:
Lowercase letters a–z
Uppercase letters A–Z
Digits 0–9
Special characters: period (.) and hyphen (‐)
Important
Currently, you can include underscores in other certificate values, such as organization units and organization names. However, the use of the underscore in these values is being reevaluated. Industry standards may change and require you to remove the underscores from those values too.
Use of double dashes violation
The Certificate Authority/Browser (CA/B) Forum clarified a requirement in Ballot 202 requiring CAs to not issue public TLS/SSL certificates with invalid internationalized domain names.
Effective October 1, 2021, for publicly trusted TLS/SSL certificates, we no longer allow the use of double dashes (--) in the third and fourth characters in domain names, unless the double dashes proceed the letters xn (xn--example.com).
Domain | Allowed? |
|---|---|
es--xyz.loudsquid.com | No |
www.es--xyz.loudsquid.com | No |
xn--xyz.loudsquid.com | OK |
xyz--loudsquid.com | OK |