Hello!
Sorting out the new cert for a new domain of mine with
certbot certonly --manual
i was ordered to provide a file under the URL domain.org/.well-known/acme-challenge/-T8jDovkL3HaotZ5bwmAQuzggvnqVjK7VZPPJCidj7U
Note the leading dash behind the final /
This is problematic in linux land. I figured it out, but beginners would be bitten by this. Could this be avoided by restriction of available characters when making up the URL?
Cheers,
tim
I guess Let's Encrypt could just regenerate the token if they encounter one starting with a dash, as a quality of life change for manual users. However, I'm not sure they would be motivated to.
The entire process is (supposed to be) automated: the only time you'd encounter this issue is if you were performing the validation process by hand. That's a teensy bit contrary to Let's Encrypt's mission.
Maybe you'll get lucky and they'll take it on board 
.
It is? I might be indeed, but I'm not familiar with that restriction to be honest. Probably an omission on my part, but if you could clearify that would be most helpful.
I'm not familiar with certbot retrying a failed authz automatically when I'm getting a certificate with e.g. certbot --apache? Or does it have to do with the Linux restriction about dashes I'm not yet familiar with? (I.e., this issue is only an issue when using --manual?)
Ah, I might understand: is it because arguments starting with a dash are seen as an option to most *nix applications? I.e., vim -T8jDovkL3HaotZ5bwmAQuzggvnqVjK7VZPPJCidj7U wouldn't work?
Because that's easily countered: most if not all *nix applications have the option to "terminate" the parsing of arguments as option by using two dashes (--). I.e.:
Doesn't work:
vim -foo
Does work:
vim -- -bar
All the arguments after the --, including the arguments starting with a dash are seen as "raw" arguments instead of a possible option to the application.
If the above is the case, this isn't actually an issue at all.
But beginners are going to be people who are least suited to using --manual anyway--automation is the objective.
Well, you're not the first to ask about this:
But generally certbot would be used with an automation plugin, and manual mode should only be used with custom scripts for handling challenges your own way. And (hopefully) anybody up to the level of writing their own scripts would know (or quickly learn) about marking end of options with -- and the like.
Yes, that's the point. Lots of things are allowed, but names have a few rules to stick to or at least most shells get hiccup when doing things like starting filenames with - or a few other special characters.
Thanks for the "head up"! I forgot about this one.
cheers,
tim
That was too obvious for me to notice...
Also I/O redirection works fine without any issue. E.g.:
osiris@erazer tmp $ echo "foo" > -bar
osiris@erazer tmp $ ls -l -- -bar
-rw-r--r-- 1 gerjan gerjan 4 Aug 30 13:54 -bar
osiris@erazer tmp $
As you can see, multiple options to manage around this issue what, personally, is therefore not a real issue at all. Certainly IMO not worth the effort of modifying the Boulder source code.
I had indeed tried quotation marks which didn't solve it; probably because fizsh is my favourite shell.
I didn't figure it was a big hassle to restrict the character set of a string, but what do i know about coding?
Quotation marks won't solve this in Bash either. My apologies if the quotes around "foo" are confusing, those quotes weren't even necessary. I just wanted to show that using I/O redirection using > would work fine with file names starting with a dash. The quotes are not the important thing in that example.
Maybe it isn't a big hassle, but as it isn't really necessary, I'm pretty sure (although not certain of course) the Boulder developers choose to spend their time and efforts into other projects 
It's probably worth pointing out that both the challenge filename and its contents are cryptographically generated, and then encoded in a standard way (I'm thinking BASE64, but I could be wrong there). Boulder doesn't come up with its own encoding scheme, and those filenames and contents aren't simply random. Thus, this is a bigger ask than it probably sounds like.
Thanks! I typically use that on other occasions, but it didn't come to mind this morning. Probably because i fell out of bed this morning!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.