10

In the common name field of the DN of a X509 certificate, as defined in ASN.1 notation for OID "2.5.4.3", the limit is up to 64 characters. Is there any turnaround if we want to have a common name of more than 64 characters?

jww
  • 97,681
  • 90
  • 411
  • 885
gingerNinja
  • 411
  • 1
  • 4
  • 12
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Information Security Stack Exchange](http://security.stackexchange.com/) would be a better place to ask. Also [Where do I post questions about Dev Ops?](http://meta.stackexchange.com/q/134306). – jww Aug 19 '16 at 10:20
  • Related, ***`CN=www.example.com`*** is probably wrong. Hostnames always go in the *SAN*. If its present in the *CN*, then it must be present in the *SAN* too (you have to list it twice in this case). For more rules and reasons, see [How do you sign Certificate Signing Request with your Certification Authority](http://stackoverflow.com/a/21340898/608639) and [How to create a self-signed certificate with openssl?](http://stackoverflow.com/q/10175812/608639) – jww Aug 19 '16 at 10:22
  • I see a 64 character limit for [`ub-common-name-length`](http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.509-201210-I!!PDF-E&type=items) in `CommonName ::= PrintableString(SIZE (1..ub-common-name-length))`. But the ***`CN`*** is a friendly name displayed to the user, like *Example, LLC Widgets*, so its probably not a problem in practice. As stated earlier, DNS names go in the SAN, so it should not be a problem in practice. Can you shorten your friendly name to fit into the 64 character limit? – jww Aug 19 '16 at 20:25
  • 1
    No, i cannot shorten my friendly name to fit into the 64 character limit? So is there any further workaround for that @jww? – gingerNinja Mar 26 '17 at 19:34
  • You might be interested in this discussion on the PKIX mailing list: [Amendment to CABF Baseline Requirements](https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ). PKIX is the IETF working group responsible for the Internet's PKI. Follow the discussion into the differences in the LDAP spec (bounded) and the CAB spec (unbounded). Its an important difference since browsers follow the CAB specs, not IETF specs. – jww Apr 08 '17 at 09:54

3 Answers3

9

Even if you could cajole your certificate generation code to have a longer CN, it's also the clients that will need to change, of which most you have no control over. Clients could well reject a certificate with a too-long CN and then you'll have no certificate at all.

As mentioned in the comments, you can (and should) put that and other domain names into the Subject Alternate Name extension and leave the CN empty. Not the whole "Subject", but just the CN part of it.

Chris Cogdon
  • 7,481
  • 5
  • 38
  • 30
4

In case you want to "cajole" the certificate generation code like @Chris Cogdon alluded to, it's not very hard. I needed to do this as part of a reverse engineering challenge and so the fact that it was against the standards didn't matter whatsoever. I completely agree with the message that you shouldn't be doing this but I'll still explain how I did it since it took a little while to figure out.

Here are the (rough) steps:

  1. Download the latest source of libressl from https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ (I used 2.6.0 because it's the version that ships on macOS Mojave)
  2. Unzip/tar/gz and then open /crypto/asn1/a_mbstr.c in your favorite editor
  3. Search for something that looks like the following:
    if ((maxsize > 0) && (nchar > maxsize)) {
        ASN1error(ASN1_R_STRING_TOO_LONG);
        ERR_asprintf_error_data("maxsize=%ld", maxsize);
        return -1;
    }

and comment it out. For version 2.6.0, this was on lines 155-159. By removing these lines, you are removing the max CN length check.

  1. Follow the directions in the README file to build the binary. I didn't need to install any libraries when I built on macOS but YMMV. I used cmake which dropped the new openssl binary in /build/apps/openssl

  2. Generate a CSR using the command line flags (read: NOT THE INTERACTIVE TOOL -- it has a special check that is not patched out by this modification!).

For example:

/build/apps/openssl/openssl req -new -newkey rsa:2048 -nodes -out a.csr -keyout a.key -subj "/CN=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

  1. Using the stock openssl binaries (or the modified ones, if you want), sign the CSR: openssl x509 -req -in a.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out a.crt -days 500 -sha256

After that, you should have your wonderful non-compliant certificate ready to use. As noted by many people in the comments and by Chris Cogdon, there are quite a few issues with using certificates with CNs longer than 64 characters (macOS curl cannot speak to servers using these certificates, Wireshark truncates the CN in the disector display, etc). This certificate, however, did work for exactly what I needed so I can at least confirm that these certificates are functional in some specific cases.

Allison
  • 2,213
  • 4
  • 32
  • 56
2

One trick I've seen out in the wild is using a wildcard certificate.

For example, a certificate with CN = '*.example.com' to secure 'very-truly-tremendously-[...]-long-hostname.example.com'.

Happyblue
  • 129
  • 1
  • 4