You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, I'm using a binary release within 2 latest releases.
Yes, I've searched similar issues on GitHub and didn't find any.
Yes, I've included all information below (version, config, etc).
What did you expect to see?
Lego creates CSRs by taking the first domain flag passed in and using it as the Common Name.
If that is longer than 64 bytes, Let's Encrypt (and potentially other CAs) reject the CSR as it is invalid.
If one of your names is shorter, you could ensure it is passed in first. But if all your names are too long, it always fails.
As a bigger ecosystem thing, the common name is going to start going away in more contexts, and it's likely that at some point in the future Let's Encrypt will start issuing certificates with no CN in the certificate if the CSR doesn't have one, or possibly even dropping CN support totally. There's no timeline for this, but I mention it as a direction this is likely to go in.
As a result, I would suggest the following changes:
Don't put a CN in CSRs by default
Add a flag to include a CSR if a user has some need for that.
The CN flag might not be required, so it's worth considering just omitting that.
What did you see instead?
urn:ietf:params:acme:error:badCSR :: Error finalizing order :: CN was longer than 64 bytes
How do you use lego?
Binary
Reproduction steps
works:
./lego -a --dns manual -d test.example.ca -d thisisthesongthatneverendsyesitgoesonandonmyfriends.somepeoplestartedsingingitnotknowingwhatitwas.andtheyllcontinuesingingitforeverjustbecause.example.ca run
doesn't work:
./lego -a --dns manual -d thisisthesongthatneverendsyesitgoesonandonmyfriends.somepeoplestartedsingingitnotknowingwhatitwas.andtheyllcontinuesingingitforeverjustbecause.example.ca -d test.example.ca run
2023/11/08 14:49:15 Could not obtain certificates: error: one or more domains had a problem:thisisthesongthatneverendsyesitgoesonandonmyfriends.somepeoplestartedsingingitnotknowingwhatitwas.andtheyllcontinuesingingitforeverjustbecause.example.ca: acme: error: 400 :: POST :: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/104658544/12129366254 :: urn:ietf:params:acme:error:badCSR :: Error finalizing order :: CN was longer than 64 bytes
Go environment (if applicable)
go version go1.20.1 linux/amd64
The text was updated successfully, but these errors were encountered:
Welcome
What did you expect to see?
Lego creates CSRs by taking the first domain flag passed in and using it as the Common Name.
If that is longer than 64 bytes, Let's Encrypt (and potentially other CAs) reject the CSR as it is invalid.
If one of your names is shorter, you could ensure it is passed in first. But if all your names are too long, it always fails.
As a bigger ecosystem thing, the common name is going to start going away in more contexts, and it's likely that at some point in the future Let's Encrypt will start issuing certificates with no CN in the certificate if the CSR doesn't have one, or possibly even dropping CN support totally. There's no timeline for this, but I mention it as a direction this is likely to go in.
As a result, I would suggest the following changes:
The CN flag might not be required, so it's worth considering just omitting that.
What did you see instead?
How do you use lego?
Binary
Reproduction steps
works:
doesn't work:
Version of lego
Logs
Go environment (if applicable)
go version go1.20.1 linux/amd64
The text was updated successfully, but these errors were encountered: