If you have concerns, questions, or other feedback about the announcement at Simplifying Issuance for Very Long Domain Names, this is the place to post them.
8 Likes
Note for anyone else testing this: If your client tries to create a CN longer than 64 bytes in the CSR that it sends, it will still be rejected as urn:ietf:params:acme:error:badCSR.
Error finalizing order :: CN was longer than 64 bytes
Though this is presumably a bug in my client.
6 Likes
Well, that's not allowed, so makes sense to reject a non-valid CSR, right? 
5 Likes
Yeah, that's an invalid CSR. I've filed an issue against Lego for this at least:
This problem was pre-existing in lego if the first --domain flag passed in was too long in that case as well.
7 Likes
Shouldn't the following:
doesn't work:
./lego -a --dns manual -d test.example.ca -d thisisthesongthatneverendsyesitgoesonandonmyfriends.somepeoplestartedsingingitnotknowingwhatitwas.andtheyllcontinuesingingitforeverjustbecause.example.ca -d test.example.ca run
be:
doesn't work:
./lego -a --dns manual -d thisisthesongthatneverendsyesitgoesonandonmyfriends.somepeoplestartedsingingitnotknowingwhatitwas.andtheyllcontinuesingingitforeverjustbecause.example.ca -d test.example.ca run
? (test.example.ca is a duplicate entry currently, at the start and at the end)
2 Likes
Ope, yeah, fixed. I copied instead of cut.
5 Likes
Well, if both lego and the library I was using (@root/acme) have the same wrong behavior of just sticking the first requested domain name in the CSR CN without paying attention to length, it may be that other clients do too. (And as you've said, this would not work with previous Let's Encrypt behavior either.) I'm not sure how many people were clamoring for the feature of allowing for longer-name-only certs (though I know some were), but it seems like it may be harder for them to actually use than one would expect.
But I did manage (by editing the CSR-creating library directly, along with the parts of the acme library that were trying to validate that the subject was right) to eventually actually get a certificate with no CN from staging.
6 Likes
Question: are there any current plans to either (i) always support CN for the legacy uses or (ii) eventually phase out the CN from all Certificates? I assume "no" for both, but if there is a decision on either it may influence some logic/design choices in ACME clients.
5 Likes
Eventually completely removing CNs is likely to happen, but we don't have a path outlined yet. I think the best thing for clients to do today is simply not include a CN in their CSR, unless a user specifically wants to set one because they know they need it.
8 Likes
I corrected an error in the API announcement: The maximum length of CNs is 64 characters, but I'd mis-remembered while writing the announcement and mis-stated as "less than 64 characters". I think I've fixed that everywhere now.
6 Likes
I'm trying to test this in staging to verify that my product can handle a cert with no CN. If I don't pass a CN at all, I'm getting this error: "Error finalizing order :: Cannot issue for "null": Domain name needs at least one dot". If I pass a name longer than 64, I get this error: "Error finalizing order :: CN was longer than 64 bytes". I'm using the acme java library (acme4j-client-2.15.jar) to issue the certificate. Is the library preventing request from going to the back end? If so, is there an update acme java library that I can use to test?
1 Like
Cannot issue for "null"
This sounds like a bug in the construction of the CSR, where the string "null" is being set as the subject instead of not setting a CN.
It looks like the CSRBuilder in acme4j-client always adds a CN, so I guess you're probably constructing your own CSR. I'd be happy to help debug your code if you'd like to share it, but I suggest you open a Client dev thread and we can work through that problem!
I've made a small test of acme4j here and verified it works with a custom CSR: https://github.com/mcpherrinm/acme4j-no-common-name/blob/main/src/main/java/org/example/Main.java#L81-L94
6 Likes
If anyone searching later is wondering: the Caddy stack (Caddy, CertMagic, and acmez) doesn't use CommonName at all (but does support them to some extent when present).
2 Likes
If this becomes the "official" Let's Encrypt recommendation, I think there's a lot of work that would need to happen to get the word out to client authors to change how they make their CSR, not to mention the additional challenge of getting users to update to a newer version even once that's done. (And then there's the question of how the user might "know they need it". If LE announced that tomorrow they would only be putting a CN in certificates for users that indicated they needed it, I bet we'd get a lot of questions from users asking how they could find out whether they needed it, without a whole lot of answers available.)
I'm not saying that any of the above is the wrong approach, just that wow is it going to be a long road to getting rid of CN, even for the "average" use case that doesn't even use it nowadays.
5 Likes
Great. Thanks.
I'll queue a task to do exactly that in my client for the next sprint - ensure that by default there is no CN, and require an explicit opt-in to select one.
6 Likes
I would say this is the official Let's Encrypt recommendation. But completely agreed, there's a long road ahead when it comes to removing the CN further. We have some ideas for ways to smooth the path, but it's going to require significant comms no matter what.
7 Likes
Thank you, you are right, the CSR was being built with "CN=null". Once I fixed that I am now able to generate a cert with no CN.
5 Likes
I am mainly thinking about this as a "whoops, something has broken because there's no CN" flag to explicitly choose a CN. They know they need it to fix a problem they're having. If you don't know what a CN is, you probably don't need one.
6 Likes
What will the Subject field look like for a CSR or certificate without CN?
3 Likes