What strings are allowed in the "common name" attribute in an X.509 certificate?

Question

In the common name field of the DN of a X509 certificate, as defined in ASN.1 notation for OID "2.5.4.3", what are the allowed values?

I know that the limit is up to 64 characters, but are all characters allowed? Digits?
E.g. are .s allowed? Is an IP address (x.x.x.x) a valid sequence per the ASN definition?
Is a domain name allowed?

The standard allows for just about any string in the common name. The meaning of a string depends on its interpretation. — President James K. Polk, Feb 28 '11 at 03:14
@GregS:So if this is the case, why is this a comment and not an answer? — Cratylus, Feb 28 '11 at 08:17
@GregS:Which standard are you reffering?Because I am interested in the type as declared in the ASN notation — Cratylus, Feb 28 '11 at 08:19
Oh sorry, I was reading RFC 5280. I didn't make it an answer because I didn't think it was detailed enough for an answer. — President James K. Polk, Feb 28 '11 at 12:07

score 65 · Accepted Answer · edited Oct 07 '21 at 05:46

The common name attribute in a Distinguished Name is encoded as:

X520CommonName ::= CHOICE {
      teletexString     TeletexString   (SIZE (1..ub-common-name)),
      printableString   PrintableString (SIZE (1..ub-common-name)),
      universalString   UniversalString (SIZE (1..ub-common-name)),
      utf8String        UTF8String      (SIZE (1..ub-common-name)),
      bmpString         BMPString       (SIZE (1..ub-common-name)) }

where ub-common-name is 64. The last three encodings allow the use of all Unicode code points (using UTF-16 for code points beyond 0xFFFF with bmpString); UTF-8 is the preferred encoding (at least the standards say so).

As far as X.509 is concerned (see RFC 5280), the contents of DN elements are irrelevant beyond equality comparisons; which means that you can put whatever sequence of characters you wish, as long as you do so consistently. RFC 5280 mandates case-insensitive comparisons for UTF-8 encoded name elements, and this is not easy in the general context of Unicode: see section 7.1, which links to RFC 4518 and 3454. Also, the "common name" is frequently displayed to the user (at least on systems using X.509 certificates which have a display and a physical user), so you probably want to use a string which is meaningful or at least not too scary for a human, and you may try to avoid non-latin scripts.

Putting a DNS name in the "common name" attribute is common practice for HTTPS server certificates: see RFC 2818 (the server certificates contains the server name, which the client matches against the server name in the URL; normally, the Subject Alt Name extension is preferred for that, but the common name is somewhat more widely supported by clients).

This answers questions that I have been asking for a long time and simply haven't found the answer to. The reference to the RFC is especially useful. — Jon Trauntvein, Apr 24 '12 at 22:22
Can anyone provide a link to a web site using something other than a DNS name for the common name? (the site name must therefore be in the SAN) — Jeff Puckett, Oct 06 '17 at 14:40
@JeffPuckett I checked quite a few, the closest I could come up with was `www-cs-01.oracle.com` which is used for `www.oracle.com`, so the CN is not the same as the DNS name although it's not what you're asking. Since CAs generally issue the certs from the portal and the portals historically used the domain in the CN, I think you'll be hard pressed to find a site that has something other than a DNS name in there. Even letsencrypt.org follows this convenstion, and they're a relatively new CA. — tresf, Feb 07 '18 at 04:47

score 8 · Answer 2 · edited Sep 22 '22 at 02:04

Whilst the above answers cover what you'll usually find in there, don't forget that because this is X.509 you can actually put pretty much anything in there. The certificate below for example uses 0.9.2342.19200300.100.1.5 which is 'favourite drink' (See https://www.alvestrand.no/objectid/0.9.2342.19200300.100.1.5.html). OpenSSL understand this, so the common name is displayed as CN=example.com/emailAddress=test@example.com/favouriteDrink=tequila. There are many other fields that can be put in the certificate common name.

You can use openssl x509 -text to verify that the certificate displays as I've described.

The link to that site does not load due to certificate errors. — Jeff Puckett, Oct 06 '17 at 14:51

score 7 · Answer 3 · edited Oct 07 '21 at 05:51

If your main problem is to know whether or not you can (or should) put an IP address in the Subject DN's Common Name, the answer is no.

This isn't related to the X.509 format, but to the specifications that say how to interpret what they read.

When it comes to HTTPS, RFC 2818 says the following about IP addresses:

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

This means that the CN shouldn't be used at all for an IP address, and that the SAN entry type must by IP address, not DNS. (Some browsers, won't implement this fully, so they might be more tolerant. The Java default host name verifier will be strict.)

Best practices for certificate identity verification are also now defined in RFC 6125, but it considers IP addresses out of scope (it's worth reading this section for arguments against using IP addresses there). If you go through the excerpts of RFCs regarding other protocols, some have similar constraints regarding IP addresses (e.g. LDAP).

@TravisThomas Indeed (in a `dNSName` extension). Just to clarify, I was specifically addressing the part of the question about IP addresses (since there were other answers for the rest already). — Bruno, Mar 30 '17 at 08:34

score 7 · Answer 4 · edited Oct 06 '17 at 14:54

7

What strings are allowed in the “common name” attribute in an X.509 certificate?

I can't really answer what goes in there, but I can tell you what does not go in there: server names, like hostnames (www.example.com), Internal Names (like www) and IP Addresses (like 127.0.0.1 or 100.100.100.100).

Placing a DNS name or server name in the Common Name (CN) is deprecated by both the IETF and CA/Browser Forums. Though deprecated, it's currently not prohibited. The CA/B is important because that's what browsers follow - browsers do not follow the IETF.

The IETF deprecated the practice in RFC 6125, section 2.3, while the CA/B deprecated the practice in the Baseline Requirements, section 9.1.1.

All server names go in the Subject Alternative Name (SAN). Placing server names in the SAN is required by CA/B Baseline Requirements, section 9.2.1. The IETF is more forgiving during issuance with RFC 5280, but requires it during validation under section 6.4.4 of RFC 6125.

edited Oct 06 '17 at 14:54

Jeff Puckett

37,464
17
118
167

answered Feb 11 '15 at 21:51

jww

97,681
90
411
885

1

awesome answer! Can you share a link to any website that does not have a DNS name in its CN? – Jeff Puckett Oct 06 '17 at 14:49
2

@JeffPuckett - try the Crypto++ website (http://www.cryptopp.com). The CN was omitted altogether. I think it was a fluke, though. I asked for a common name of *"Crypto++"*, but I think software that handles the issuing filtered the name because some scripts may interpret the plus'es as regular expressions. Derp... – jww Oct 06 '17 at 15:07
thank you, that's great! please ping me again if you happen to come across one in the wild that has a value or anything other than a DNS name. – Jeff Puckett Oct 06 '17 at 15:10
@JeffPuckett - Also remember the CN is only one part or piece of the Distinguished Name (DN). There are two important DN's. The first is the subject's DN (who the certificate was issued to), and second is the issuer's DN (who does the issuing). The entire DN string is the important part; and a missing RDN like CN or State does not matter too much. There's an RFC covering DN's; its the one that covers directory names. – jww Oct 06 '17 at 15:10

What strings are allowed in the "common name" attribute in an X.509 certificate?

4 Answers4

Linked