What strings are allowed in the “common name” attr

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?

Answer 1

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).

Answer 2

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.

Answer 3

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 http://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=[e-mail]/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.

-----BEGIN CERTIFICATE-----
MIIDOzCCAiOgAwIBAgIBCzANBgkqhkiG9w0BAQUFADCBqzEmMCQGA1UEAxMdV2Vz
dHBvaW50IENlcnRpZmljYXRlIFRlc3QgQ0ExEzARBgNVBAgTCkxhbmNhc2hpcmUx
CzAJBgNVBAYTAlVLMR0wGwYJKoZIhvcNAQkBFg5jYUBleGFtcGxlLmNvbTFAMD4G
A1UEChM3V2VzdHBvaW50IENlcnRpZmljYXRlIFRlc3QgUm9vdCBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTAeFw0xMTA3MzEyMTAxMTdaFw0yMTA3MjgyMTAxMTdaMFAx
FDASBgNVBAMTC2V4YW1wbGUuY29tMR8wHQYJKoZIhvcNAQkBFhB0ZXN0QGV4YW1w
bGUuY29tMRcwFQYKCZImiZPyLGQBBRMHdGVxdWlsYTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAuCqI3aNbSkRpA9VuGOmeVQ010Oaawsz4tcW2FQChJDOv6PuT
ucy5IijvaVewotDjnuVzPpBVW5EmC8Qapradomhb6FtFPyH/hGSnhLtht3Ln6stJ
ZkAjvr/wjWDy+3Gy/P5r5weUNWVm2AaQgk2xumx49EIXyzwOEHAhqTE7iEECAwEA
AaNIMEYwCQYDVR0TBAIwADA5BggrBgEFBQcBAQQtMCswKQYIKwYBBQUHMAGGHWh0
dHA6Ly9vY3NwLmV4YW1wbGUuY29tOjg4ODgvMA0GCSqGSIb3DQEBBQUAA4IBAQBL
oz035PphO4yUx7FJVaZjxLgTM4wLrcn2ONGm015/ECO+1Uxj3hWb6/EIDDKV/4e8
x0HDF69zyawYLD1th5tBcZLkV/Dat/Tzkt3boLOCGo2I1P+yjqxlb7BZCk7PEs3+
zjWF2hMcXtAwOIrsRuvXp4eTGwigKLAt/H02US/fa2dXFbOnz91V7oH8ZvynIl/n
hpELPzVWX/pBnHEGA9Bi0jviCKuvQisfaJ8XCiA73qH6CkSoZ2fClnrs+pJNj8i6
vtcMx8htn7FsyB3puVww86JSQ+VDKlQkFbPVla/4Aavzwz8djjVYEWwSgm+tw3jB
zUP/k5Aln5cXNo50KOip
-----END CERTIFICATE-----

Answer 4

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).