It seems that the challenge file name can be somewhat annoying every once in a while:
Example: “-VpOzEjDrFmAsMu32cvna-JQTbpH4EBIhNcWPvhBtO4”
I think the generator should really be modified to NOT use a dash as the starting character of a file name, it makes it unnecessarily hard to manage.
What’s special about a dash as first character?
Most Linux/Unix commands treat the dash as an option character, similar to the forward slash on Windows. Most of those also accept "--" as a separator to say "anything after here is a parameter and not an option". But novices might not be aware of that. So they might type cp -VpOzEjDrFmAsMu32cvna-JQTbpH4EBIhNcWPvhBtO4 /var/www/html/.well-known/acme-challenge/ and wonder why it didn't work.
see jmorahan’s reply 
Ah of course, right.
I am also against the .wel-known because it’s a pain to create in windows.
you can create a dot-folder by appending a dot (".well-known.") and the dot gets removed but that’s certainly NOT common knowledge and if you just name is “.well-known” then windows says that I should specify a file name.
.well-known is a “well known” standard. cmd.exe has no problems creating dot-files with mkdir.
assuming you know your way around cmd.
This is still a thing?! Just got this as the file to create:
"-Fh8pd2cssyoElPMTdXGT73a_PAlYFjbCq3nonLoyZU"
c'mon man.
I'd guess it's "still a thing" because it has never really been a pressing issue that any significant percentage of users run into. The goal of the ACME protocol and Let's Encrypt is automation. Automated tools have no problems with the file names. Only humans do and rarely at that.
I agree with @rmbolger: this was hardly a thing to begin with and does not warrant an upstream change.
As a human experienced in this stuff, I really hate the leading dash.
That being said- when this ticket topic was started, the clients/plugins were very limited and humans often had to intervene. Today, the ecosystem of installers are greatly expanded and it is rare for a human to interact with a challenge file.
@vpimentel why are you creating a file in 2022? what conditions forced you to not use an existing client/plugin that automated this? that's a bigger problem that we should solve.
What are the odds of a dash appearing as the first character? [how often does this problem occur?]
[or does it "break" regardless of where the dash appears?]
I believe it's base64url encoding, and the value is random, so 1/64 challenges will start with a dash.
token (required, string): A random value that uniquely identifies
the challenge. This value MUST have at least 128 bits of entropy.
It MUST NOT contain any characters outside the base64url alphabet
and MUST NOT include base64 padding characters ("="). See
[RFC4086] for additional information on randomness requirements.
The path at which the resource is provisioned is comprised of the
fixed prefix "/.well-known/acme-challenge/", followed by the "token"
value in the challenge. The value of the resource MUST be the ASCII
representation of the key authorization.
Correct, you can see this in the Boulder code:
So its the base64url-encoding of a 32 char long byte array.
And indeed, the - is on of the 64 possible base64url characters.
In conclusion: an enormous amount of tokens used by the Let's Encrypt CA (2 million certs per day issued! Although not all of those certs require new tokens..) would start with a dash.. And it's not very often someone complains about it.
If the randomness is balanced, then a (1/64) failure should be followed by a (63/64) success.
If the death is claimed after even three consecutive failures...
Then it's a one out of (64*64*64) chance!
[2^18]
OR
Could be checked before returned and rejected if it starts with "-" and regenerate an new b.
RFC4086 probably won't like that.
That's true, but the context in which this entropy is used in the protocol is an especially safe less unsafe context in which to lose a little bit of entropy.