Bridge SSL
What is the certificate CN? The common name field
The common name (CN) is a naming attribute in the subject and the issuer of an X.509 certificate. RFC 5280 lists it among the attribute types every implementation must be prepared to receive, and its example value is a person's name, "Susan Housley" [1]. Certificates often carried a website's hostname there as well [3]. Today the hostname belongs in the subject alternative name (SAN): RFC 9525 says the common name must not be used to identify a service [2], and the CA/Browser Forum Baseline Requirements allow it in a website certificate only as a copy of one subject alternative name entry [4]. It is one of the terms in the SSL and TLS glossary.
- Found in
- subject and issuer names [1]
- Name checks
- not used; the server identity is only in the subject alternative name [2]
- Website certificates
- not recommended; if present, a copy of one SAN entry [4]
- CA certificates
- required [4]
Where the CN sits in a certificate
The subject and the issuer of a certificate are distinguished names: a sequence of relative distinguished names, each a set of one or more attribute types with their values [1]. The common name is one of those attributes, id-at-commonName, number 3 under the arc 2.5.4, so its OID is 2.5.4.3 [1]. Its value holds at most 64 characters, the upper bound ub-common-name [1]. In a publicly trusted certificate each relative distinguished name holds exactly one attribute, and the CN must be a UTF8String or a PrintableString; the limit of 64 counts characters, not bytes [4].
Subject and issuer in a test certificate
A test certificate shows both places. The authority is Example Test CA, the site name is www.example.com, and the tool is OpenSSL 3.0.13:
$ openssl x509 -in leaf.pem -noout -subject -issuer -ext subjectAltName
subject=CN = www.example.com
issuer=CN = Example Test CA
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.comopenssl asn1parse decodes both values as the object commonName followed by a UTF8STRING. The issuer line is the common name of the test authority. In a certificate authority's own certificate the Baseline Requirements make the common name mandatory, and its contents should make the certificate's name unique among the certificates its issuer has signed [4]. RFC 5280 requires the subject of a CA to match the issuer field of every certificate it issues [1], which is why the authority's CN reappears there. The full list of certificate fields is in the X.509 entry of this glossary.
How name checks use the CN and the SAN
Under RFC 9525 the common name plays no part in checking a server's name. Its summary of rules starts with this one: "Only check DNS domain names via the subjectAltName extension designed for that purpose: dNSName." The same summary says not to include or check strings that look like domain names in the subject's common name [2]. The reason it gives: the common name is not strongly typed, it is essentially free-form text, and so it can be read in more than one way. The same rule covers every other attribute of the subject name [2].
RFC 9525 obsoletes RFC 6125, which still had a fallback. A client could check a domain-like string in the common name as a last resort, and only if the certificate presented no DNS-ID, SRV-ID, URI-ID or other identifier type the client supports [3]. RFC 9525 removed it: the server identity can only be expressed in the subject alternative name, and using the commonName, which RFC 6125 called a CN-ID, is no longer valid [2].
When the name does not match
The client builds its list of acceptable names, the reference identifiers, from its inputs, such as an address the user typed, and independently of what the server presents. It compares them with the presented identifiers, the names in the certificate, and the search fails when no reference identifier finds a match [2]. On a name mismatch an automated client should end the connection with a bad certificate error. A client that a person uses directly should tell the user about the mismatch and end it, and may let advanced users proceed [2]. Under RFC 9525, a hostname that appears only in the common name does not match.
The server can choose its certificate by that same name. TLS Server Name Indication lets the client tell the server the name it wants, and the server can then use it to select the most appropriate certificate [2].
A client may also offer to accept a mismatched certificate for later connections. RFC 9525 says such ad hoc pinning should not restrict future connections to that one certificate, and a fixed certificate for a peer should be set only in prior configuration, not in an override after a failed connection [2]. Configuring that in advance is covered under pinning a certificate.
What the Baseline Requirements allow
The Baseline Requirements govern publicly trusted TLS server certificates, and they treat the common name differently by certificate type [4]:
| Certificate | Common name | Section |
|---|---|---|
| Website certificate, DV, IV or OV profile | not recommended; if present, a value taken from the subject alternative name | §7.1.2.7.2, §7.1.2.7.3, §7.1.2.7.4 |
| CA certificate | must be present | §7.1.2.10.2 |
| Any certificate, in the subject | UTF8String or PrintableString, up to 64 characters | §7.1.4.2 |
What a website certificate's CN may contain
When a website certificate has a common name, section 7.1.4.3 fixes what it may contain [4]:
Exactly one entry, and it must be one of the values in the certificate's subject alternative name.
An IPv4 address in the form of RFC 3986, section 3.2.2; an IPv6 address in the text form of RFC 5952, section 4.
A domain name or a wildcard domain name as a character-for-character copy of the dNSName entry. Labels stay in their LDH form, and Punycode labels, the P-Labels, are not converted to Unicode.
So a website certificate can follow these rules in two ways: leave the common name out, or copy one subject alternative name entry into it exactly. Because the common name is capped at 64 characters and must copy an entry, a longer hostname can never be the common name [4]. Subject alternative names, and how one certificate lists many of them, have their own page in the certificates section.
A certificate without a common name: a test
RFC 5280 allows an empty subject when all the naming is in the subject alternative name. The subject is then an empty sequence, and the subject alternative name extension must be marked critical [1]. In openssl req, a single / given to -subj produces an empty sequence of relative distinguished names [5]. Signed by the test authority with a critical subject alternative name, the certificate reads:
Subject:
X509v3 Subject Alternative Name: critical
DNS:www.example.com, DNS:example.comIn this test, OpenSSL 3.0.13 enforced the 64-character limit on the common name and not on the subject alternative name:
| Test | Result |
|---|---|
| Common name of 64 characters | openssl req exit code 0 |
| Common name of 65 characters | openssl req exit code 1: string too long, maxsize=64 |
| The same 65 characters as a dNSName in the subject alternative name | certificate signed, exit code 0 |
| Empty subject, subject alternative name marked critical | certificate signed, Subject: empty |
FAQ
What does CN mean in a certificate?
Can the common name be an IP address?
In a publicly trusted website certificate, only if the same address is in the subject alternative name. An IPv4 address is written as in RFC 3986, section 3.2.2, and an IPv6 address in the text form of RFC 5952, section 4. [4]
Sources
RFC 5280, Internet X.509 PKI Certificate and CRL Profile: §4.1.2.4 (issuer), §4.1.2.6 (subject), §4.2.1.6 (subject alternative name), Appendix A (id-at-commonName, ub-common-name).
RFC 9525, Service Identity in TLS: §1.3, §2, §6.1.1, §6.2, §6.6, §7.5, Appendix A.
RFC 6125, Representation and Verification of Domain-Based Application Service Identity: §2.3, §6.4.4.
CA/Browser Forum Baseline Requirements, version 2.3.1: §7.1.2.7.2 to §7.1.2.7.4, §7.1.2.10.2, §7.1.4.1 to §7.1.4.3.
OpenSSL 3.0 manual: openssl-req, option
-subj.