SSL for (a) 63 character (max. number of characters) - domain name(s)

Dear ‘Let’s Encrypt’ - community & SSL - experts,

who ever thinks that it is possible to add a SSL (https) to a - and therefore also to the following - 63 character domain name* is welcome to show me just one (other, active, exisitng ** ) 63 character - domain name with a SSL (https) as an evidence that it is indeed possible:

*highest possible number of characters at the left side of the dot before the TLD
**you can register any domain name with 63 characters to try it

IMPORTANT: The SSL must work WITH and WITHOUT the ‘www.’ before the domain name.

If you will be able to do that, you will probably be the first one who did it.

Best regards & good luck!


I’m a bit confused about what the nature of this challenge is. Are you asking because you don’t know the answer to your question, because you’re having trouble with Let’s Encrypt in particular, because you think some of the Internet standards are ambiguous or not being followed properly, or because you do know the answer and want to challenge other people on the forum to figure it out?

1 Like

based on your claim I tried a 63 digit subdomain (which should resemble your TLD claim) and did recreate your claim:
2017/06/18 21:50:30 Could not generate a CSR: Unexpected CSR error.

Reducing the subdomain length 1 digit at a time.
It only began to work with 53 digits (10 less than allowed).

So, OK, your claim is confirmed: Unable to generate cert with >53 continuous chars (excluding dots).
@schoen Internet standards are not being followed properly.
Probably a typo: “53” in code should have been “63”.

1 Like

Hi @schoen,

the nature of this ‘challenge’ is that I am trying to find out if there is someone in this world wide web who is able to create / show me a 63 character domain name with a SSL because based on my past experiences it seems that it is not possible but I can’t believe that becasue every registerable domain should can get a SSL.

So yes - every of your assumptions is correct in some way.

OK, I think the appropriate thing would be to look at a Certificate Transparency database or at EFF’s SSL Observatory database. I don’t happen to know of a web interface to search by length of subject names.

You could also do well by downloading HTTPS scans from

and then searching them, although they may be large files and it also requires creating an account.

Maybe we could invoke @jsha’s Internet protocols knowledge and ask him whether he’s aware of the technical or policy limitations on the length of a registered domain and/or subject name in an X.509 certificate or CSR. I think we talked about this topic a while ago.

1 Like

Thank you for your feedback, it seems you too failed with this ‘task’.
But it dosn’t mean, that you will not be able to find a way at another time.

My point is, if it’s possible to register domain names with 63 characters, then it should be possible to protect them with a SSL.

It’s an interesting thought that it could be the result of typo - but I really don’t believe that.

Thank you for your help and suggestions.

I am not an expert in this SSL subject(s) - that’s why I don’t understand what you are talking (writing) about - sry - and that’s why I formulated my original post in the way I formulated it.

Maybe you were talking with WIX about this issue, that’s where the mentioned domain is currently hosted and they are offering SSL from ‘Let’s Encrypt’ for ‘every domain hosted with them’* - but they were and they are still not able to add the SSL to this domain.

*WIX is writing on their site:
All Wix sites have been enabled for HTTPS.

I agree that any domain that conforms to standards should be able to obtain an SSL cert.
I was able to reproduce the error with lengths:
23.30(.6.3 tld)
and it worked with:
22.30(.6.3 tld)
So when length of anything left of tld >53 = "Could not generate a CSR: Unexpected CSR error."
So it seems that any combination of subdomain lengths also breaks this.

1 Like

Ok - so then the ‘error’ is that the ‘technical SSL rules’ are definitely not up to date.

The Common Name field has a length limit of 64 characters.

As far as i know, there is no problem with lengthy Subject Alternative Names, though.

You just have to put a shorter name in the Common Name, or leave it out.


-d short.simple.dom -d 63chars.simple.dom
to a cert request works!!!

So if your Subject Name is “too long”… you can’t get a cert for your legitimate domain.

1 Like

This sounds kind of familiar.

Let’s Encrypt may eventually stop putting domain names in the CN field at all, because there’s a major movement to deprecate this. Instead it may contain a serial number or something.

I believe that you can make a CSR that Let’s Encrypt will accept with no CN field at all, only with SANs. However, the current CA practice might nonetheless try to put one of the domain names into the CN field, even though the CSR didn’t request it, and that might fail if that domain name can’t fit into the CN.

1 Like

Yep, the conclusions in this thread are correct. To summarize:

The X.509 Subject field “CommonName” is limited to 64 characters per RFC 5280, pages 120 and 124:

CommonName ::= PrintableString (SIZE (1…ub-common-name-length))

ub-common-name-length INTEGER ::= 64

SubjectAlternativeNames has no such restriction, and for DNS names is only bounded by the DNS maximum (255 characters). It is permissible to have an empty subject per RFC 5280, page 24:

If subject naming information is present only in the subjectAltName extension
(e.g., a key bound only to an email address or URI), then the subject
name MUST be an empty sequence and the subjectAltName extension MUST
be critical.

So one could create a certificate with an empty Subject, and a long DNS name in the SubjectAlternativeNames, and it would be RFC 5280 compliant. However, such certificates create known compatibility problems with some major user agents. Try and if you are curious to see whether any given user agent fails to validate. Until recently, Chrome on Mac would fail to validate such a certificate.

To avoid creating compatibility problems, Let’s Encrypt never issues with an empty Subject. Another approach, which should be broadly compatible, would be to insert a “junk” field other than CommonName in the Subject. We originally thought to do this by copying the serial number field into the subject, but it’s been suggested that the Baseline Requirements would term this “Subject Identity Information,”

Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.

Since Let’s Encrypt uses the CA/Browser Forum domain-validated OID ( in its certificates, the certificates are not supposed to have Subject Identity Information:

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (, if the Certificate complies with these Requirements but lacks Subject Identity Information that is verified in accordance with Section or Section 3.2.3.

So currently our plan is to support a CA/Browser Forum ballot allowing the dnQualifier attribute in Subjects without it being considered Subject Identity Information, and then start adding that in place of CommonName.

In the meantime, the workaround of including a shorter name in CSR’s CommonName field works well (as the original poster discovered).

[Update September 2018: The dnQualifier ballot at CA/Browser Forum failed over compatibility worries. There may be another ballot at some point, but for now progress on this front is stalled]


Thank you all for your explanations, I really appreciate all your answers.

I will now contact my hosting provider (WIX) to let them know about this helpful thread so that they can learn how to provide me a SSL for my mentioned domain through the described workaround.

When the common name would exceed the RFC, it could be replaced/substituted with “Serial Number”

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.