Thanks, so openssl req -subj /. Such Subject is not very informative 
4 Likes
Yes. A complete openssl command would look like:
openssl req -new -key private.pem -addext "subjectAltName=DNS:example.com,DNS:example.net" -subj /
4 Likes
So the only options will be a "traditional" Subject (with CN= followed by a validated hostname) or empty Subject, not arbitrary Subject's with or without arbitrary CN's, right?
3 Likes
Correct, Let's Encrypt never includes any information in the Subject other than the Common Name. Including any other fields would be a violation of our CP/CPS and the Baseline Requirements, as such certs would not be "Domain Validated" and we are (purposefully!) not capable of validating the information that would be contained in any other Subject fields.
7 Likes
Well the subject can also contain fields other than the Common Name (country, organization and many more). Let's Encrypt appears to ignore these when contained in a CSR, so you don't have to use an empty Subject in the CSR - just don't send a CN (acme.sh for example fills the subject with a dummy organization field for IP address certificates).
However, this is only Let's Encrypts current behaviour: Other CAs might have different opinions on that. The final certificate will never have more than the CN in the subject for a domain-validated certificate though.
6 Likes
That line seems incomplete - it ends with a "slash"
[which normally implies the command continues on the next line]
OR
The "slash" is the actual value for the parameter and should have been in quotes.
2 Likes
No, that’s correct. A \ (backslash) escapes the next character, including new lines, but this is a forward slash, which doesn’t require any quoting.
5 Likes
OK, so my eyes are the problem - LOL
4 Likes
Aye my friend. 
2 Likes
Just to clarify, there's no actual requirement to remove common name from the CSR at this point is there?
I'm just checking because there's an implied thread here that authors would perhaps be scrambling to clean up clients that do supply a common name (obviously we all supply the SAN list anyway), but apart from being somewhat antiquated I don't see the problem in supplying it, and CAs will still presumably vary in their behavior.
1 Like
The CN field in CSRs is capped at 64 characters, so if you want to use the new feature to issue certs with all names over 64 characters, you cannot include a CN in that case. I think the simplest way to fix this issue is to just always remove it.
6 Likes
Not sure which other clients/projects might be affected, but it looks like the C# BouncyCastle crypto library (at least the version I'm currently using) does not enforce CN length limits in their Pkcs10CertificationRequest class. So I'll be adding that to my own internal function that wraps it for CSR creation in Posh-ACME.
5 Likes
Note that not enforcing the max CN length would have potentially gotten the user in trouble long before this change
2 Likes
In addition, people looking at this is exposing a bug in many clients, where even if there is a name that would fit in the CN, the client is putting the first supplied name in the CN regardless of length. But this would have not worked with prior Let's Encrypt behavior either.
Sure, but I think that clients should consider providing an option to specify a CN. There was the case earlier this year where Let's Encrypt's server changed the behavior of which name was put in the certificate CN if the CSR didn't include one, and that broke some people's workflows because they didn't realize that their client wasn't setting it in the CSR.
5 Likes
Yes this is what we have in Certify The Web, it's just because on Windows there's often UI for various apps or services that still expose the primary subject (non-web servers etc, confirmation dialogs etc), so people like it to be something sensible even when they have stuffed their cert with a bunch of other names so that it can match screenshots in training material etc.
Nobody has ever reported an error with a long domain to us (as far as I can recall), but maybe the LE error was enough to discourage them from trying further long names and that's why it's not been a problem.
1 Like
We haven't encountered any significant reports of issues, so we are going ahead with deploying this to production tomorrow, about 24 hours from this post.
7 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.