Add support for ACME_CHALLENGE_DIR environment variable

[chr4]

trafficstars

Add support for an ACME_CHALLENGE_DIR environment variable. If the variable is set and -manual=true is given, automatically place the generated challenge file in $ACME_CHALLENGE_DIR/.well-known/acme-challenge.

This is helpful when batch-processing the retrieval of certificates.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[chr4]

Signed it.

[googlebot]

CLAs look good, thanks!

[x1ddos]

Thanks for this. Quite useful. I would make it an additional command line arg first and then add ACME_CHALLENGE_DIR as an alternative way of defining flags.

Otherwise, we start mixing env vars and flags, and it'll become harder to use the tool.

[chr4]

Thanks for the feedback! I'm open for both, environment or cmd flag, I just used an env because the other directory ACME_CONFIG was also set via the environment.

[x1ddos]

Right, there's indeed ACME_CONFIG but it's an alternative to -c cmd line flag. We could replace -s host:port flag with -l <host:port|local_dir>, trying to avoid too many flags. wdyt?

[chr4]

First thought is, that parsing host:port is not that easy, as theoretically it's possible to have a filename containing the : character. This might not even that unlikely, if someone uses /var/www/example.com:81 as a root dir for a service on port 81. We could use file:/// as an indicator, but it feels not very intuitive.

What about renaming/ using the -manual flag to accept a path argument, and use interactive mode if the path is empty or true? We could also consider removing the interactive mode completely. Is there a scenario where it is useful when it's possible to specify the path using a flag?

[x1ddos]

Is there a scenario where it is useful when it's possible to specify the path using a flag?

Well, yeah. for instance, https://getmdl.io is served from a GCS bucket and that's how I get it working with Let's Encrypt cert - placing a temporary token file into gs://my-bucket/.well-known/..., which is then accessible to the CA as getmdl.io/.well-known/... to verify domain ownership.

I can see many other options, e.g. AWS S3 or another kind of storage not accessible directly via file system calls.

Agree on mixing host:port with a local dir is bad, but hesitant on reusing -manual as it feels the opposite to me: manual means the program is handing over control to a human.

Note that -s host:port could also be used for resolving TLS-SNI challenges in the future, not only HTTP-01.

Maybe then another flag would work? Say, -http01-dir=path/to/root to indicate this is used only for a specific challenge, which will also mean -s and -http01-dir are mutually exclusive.

[chr4]

It seems to me that a new (mutually exclusive) flag indeed seems like the most straightforward idea. -http01-dir sounds good to me.

[x1ddos]

Forgot to add, having -http01-dir arg will also allow future implementations for non-fs storages:

# GCS bucket
-http01-dir=gs://bucket
# AWS S3
-http01-dir=s3://bucket
# ssh/scp
-http01-dir=ssh://user@host:path/to/root