ASN1_mbstring_ncopy string too long with multiple alt-names about acme-spec HOT 3 CLOSED

This sounds like a bug in the client. You want to post it at:
https://github.com/letsencrypt/boulder/issues

On Tue, Nov 10, 2015 at 8:01 AM, Izzy [email protected] wrote:

As Let's Encrypt doesn't support wildcard certificates, we have to use
multiple subjectAltNames. Unfortunately this leads to a problem if the list
exceeds a certain length (I guess #183
#183 is related here).
In my specific case, the list ends up with 97 chars – and I receive the
following error:

Error: [('asn1 encoding routines', 'ASN1_mbstring_ncopy', 'string too long')]

I played with it a little, having the same error with 67 chars – but no
longer when coming below 65 chars. So the list of host names is limited to
64 bytes, including the separators. Unfortunately, for the affected host I
cannot use multiple certificates (i.e. a separate cert for each host name)
– I need a certificate holding all the hosts.

Any way to get that working? Note this could already happen if the cert
should cover 2 hosts with a long name (64/2 = 32, so if the length of both
host names is 32 char (making up an example:
testengine32.special-junkies.org has exactly 32 char), it would already
break.

A sanitized stack-trace can be found at pastebin
http://pastebin.com/vs60WXn2 if needed.

System: Ubuntu 12.04 64bit.

—
Reply to this email directly or view it on GitHub
#232.

from acme-spec.

Update: it seems to work with the domain names specified at the command line (-d host1 -d host2 …). Checking the resulting .conf file in /etc/letsencrypt/renewal showed domains separated by comma and space (e.g. domains = host1, host2, …) – while I had separated them only by spaces (which works fine when not exceeding 64 bytes). Trying it again with the same operators in my config file (passed using the -c config.ini parameter) breaks as well with the same error – so this seems to be a limitation of the config file to pass with -c.

Currently I can live with the mentioned work-around. Would be nice to see it fixed, though.

@ekr Oh – I see, I've hit the wrong place. Blame my Google-Fu, and apologies!

from acme-spec.

OK, moved the issue over here – @ekr is right, it doesn't target the spec but rather a bug in the client. Hence closing this issue, having "the task moved" to the right place (hopefully).

from acme-spec.