certlint disapproves of a very long CN that Let's Encrypt issued for

[schoen]

Hi, please see https://github.com/letsencrypt/boulder/issues/1488 (just so you're aware of this and can figure out who was correct in this instance -- Let's Encrypt or certlint).

[jmhodges]

This is not a certlint bug. We are fixing this in boulder right now.

[eabalea]

From RFC5280:

-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
-- expanded to:
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)) }

-- later on
ub-common-name INTEGER ::= 64

certlint is strict but right. Let's Encrypt could replace the CN by something like "this FQDN is too long to be stored here <"|| some random stuff ||">", or try to delete the CN completely and see how things work (it's correct to have an empty Subject, if the SAN is set to be critical). Anyway, browsers ignore the content of the CN if the SAN is present, CN use is deprecated, etc.

[schoen]

Sorry for the noise, but I'm glad to have a clear answer about this!

[schoen]

Incidentally, the boulder team has now fixed this in boulder, so thank you to certlint for help enforcing spec compliance.