I've been working with the LE dns-01 and http-01 challenges for a few years now, and have a fairly robust service that's been generating certs without issue for a while. In the past month I have started to have issues in our infrastructure because the CERTBOT_VALIDATION that LE provides to us starts with a "-" and this breaks the gcloud cli that we are using to create the DNS record. This feels like something that could potentially be a minefield for other DNS clis like AWS.
Basically, we'll get a string like "-RX5OHTYGcuOSRA8Hdeb7HAFKSTATNZQJZWs_Es2UEY" this gets injected into a command like gcloud dns record-sets transaction add "-RX5OHTYGcuOSRA8Hdeb7HAFKSTATNZQJZWs_Es2UEY" --ttl=30 --zone=myzone --name=X --type=TXT. But, the gcloud CLI bombs on it because it thinks that the validation token is a command argument ERROR: (gcloud.dns.record-sets.transaction.add) unrecognized arguments: -RX5OHTYGcuOSRA8Hdeb7HAFKSTATNZQJZWs_Es2UEY. I have tried a bunch of variants, including posting a StackOverflow specific to the gcloud cli (bash - gcloud cli failing to add record when contents start with dash - Stack Overflow). I'm wondering if it's possible to just not generate challenges that start with or contain a dash as it seems like just a recipe to make things more complicated than normal. The old format of A-Za-z0-9 worked and is there really a difference cryptographically by the inclusion of "-" and "_"?
Try prefixing the value with \ (or perhaps even \\ depending on where the string gets interpreted) to escape the - , haven't tried it myself but you never know. This is a bug/feature of the gcloud cli so although it could be worked around they should really fix it. Make sure you are on the latest gcloud cli version.
I can confirm the following works: gcloud dns --project=myprojectid record-sets transaction add \-test123 --name=test.mydomain.com. --ttl=300 --type=TXT --zone=myzoneid
While a part of me believes Boulder should aim to create challenges that avoid problematic client issues like this, the real underlying problem is a buggy client.
Putting things in quotes as you did is the correct and expected way to deal with those characters in pretty much every computing environment. It should behave identical to what @webprofusion suggested as a workaround (using escape characters with unquoted arguments). You should report this bug to gcloud. Google has more than enough money and engineers on staff to finance fixing their own bugs. They shouldn't rely on Open Source projects and volunteers to work around their mess.
@jvanasco I agree, it is not your problem. I posted it here because maybe you'd be open to it, but I certainly don't think it's something you have to fix. It's ultimately Google's fault. I have created an issue for Google to address: Sign in - Google Accounts .
@webprofusion When I try your solution I have to quote it and escape the "-", then it works. So your posted solution errors for me on gcloud 347.0.0 with unrecognized arguments: -test123, but if I instead do it as:
Thanks for the clarification. Many people come here, and countless other projects, and insist an issue with Google or another commercial vendor's implementation must be fixed by that project.
I do believe the Boulder maintainers should consider limiting the starting character of challenges to deal with bad clients, and you should open a ticket there. That is in the best interests of this project and the internet. This is just one of those issues where a bug should first be filed with the client, and they should be fixing it independent of this project's efforts.
Most command line applications have the option to terminate the option parsing feature with two dashes: --
I.e., the following command:
foo --bar -- -baz
would be interpreted as:
application foo
option bar
argument -baz cleanly passed to the application without trying to parse it as an option
That said, obviously you wouldn't be able to use any option any longer after the --, so if the command doesn't support some sequence of options where you can enter the argument starting with a dash which isn't a command line option, but only somewhere between multiple options, this won't work.
