Challenges starting with a "-" are problematic

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 "_"?

1 Like

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 --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.

1 Like

@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:

gcloud dns --project=myprojectid record-sets transaction add "\-test123" --ttl=300 --type=TXT --zone=myzoneid

That works for me, thanks for the work around!


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.


@Osiris That works, and it's simpler because I don't have to deal with escaping or quoting.

gcloud dns record-sets transaction add --ttl=30 --zone=myzone --type=TXT -- -E_ASD-FS-DF

Cool, it worked! :smiley:   

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.