Caddy: Preset for LetsEncrypt staging url

[tobya]

I'm just starting a discussion to see if this is something we would like to do.

I have been spending a bit of time recently using the staging environment for lets encrypt, which involves doing this

caddy -ca https://acme-staging.api.letsencrypt.org/directory

now I'm pretty organised and use ditto to store my clipboard copies and so always have the url on hand, but it got me thinking that perhaps something like this might be nice

caddy -ca staging

which internally would be the same as above. You could of course also supply a https url like normal.

This could cause an issue if LetsEncrypt changed the url, but presumably they won't do that very often and users would still be able to specify it?

Would a PR with this change be likely to be merged?

[francislavoie]

FWIW, you could just put this in your Caddyfile now (since https://github.com/mholt/caddy/pull/1699) and comment it out when you don't need it:

tls <email> {
  ca https://acme-staging.api.letsencrypt.org/directory
}

But I agree this would be useful

Edit: Actually, to add onto this, I think a --staging flag would be better design potentially, because that's the way Certbot does it in its commandline tool. See the mention here: https://letsencrypt.org/docs/staging-environment/

[mholt]

because that's the way Certbot does it in its commandline tool

True, but certbot is specifically a Let's Encrypt client; Caddy is designed to be compatible with other ACME servers, not just Let's Encrypt.

And soon, Let's Encrypt will have a v2 endpoint, which may (or may not) have a different staging endpoint.

I think having a special value here will be too ambiguous.

[gerhard]

FWIW, since Caddy v0.10.12, the Let's Encrypt Staging URL must be set explicitly to https://acme-staging-v02.api.letsencrypt.org/directory, otherwise caddy will fail to start with Activating privacy features... directory missing new registration URL.

Update 2018-04-28

This is the Caddyfile.tpl example snippet - Terraform template -, that works for me with Caddy v0.10.14:

${fqdn} {
  tls ${email} {
    ca https://acme-staging-v02.api.letsencrypt.org/directory
  }
...
}

[unquietwiki]

Hey @mholt : I'm getting the same error @gerhard is talking about here on a Caddy 0.10.14 compile, unless I manually set the CA to https://acme-v01.api.letsencrypt.org/directory ; figure its an old dependency, or that I'm not using wildcards?

[elcore]

@unquietwiki Caddy does not support ACME v01, you will have to use ACME v02.

[unquietwiki]

I must have imported an older library then, or something. It worked with
warning certs from v2; but for valid prod, it needed v1.

On Sat, Apr 28, 2018, 12:18 AM elcore [e-mail] wrote:

@unquietwiki https://github.com/unquietwiki Caddy does not support ACME
v01, you will have to use ACME v02.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mholt/caddy/issues/1755#issuecomment-385148220, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA9fv-H4YgbXb08-dXVo2MGaLc1EG0WFks5ttBfagaJpZM4OR0FA
.

[mholt]

The ACMEv2 staging endpoint, required as of Caddy 0.10.12, is: https://acme-staging-v02.api.letsencrypt.org/directory

[unquietwiki]

@mholt @elcore Clarifying earlier. Staging v2 worked for me; production v2 did not, but production v1 did. Odd, I know.

[mholt]

Huh, weird. Could be a temporary hiccup.

[unigazer]

Hello,
I was struggling with the staging server while trying to run Caddy in a Alpine Docker image. So, if anyone experiences error like this in the CI (I was using GitLab's):

[example.com] failed to get certificate: [example.com] error presenting token: presenting with standard HTTP provider server: Could not start HTTP server for challenge -> listen tcp :80: bind: permission denied

or

listen tcp :443: bind: permission denied

To fix it, add this command in Docker

RUN setcap CAP_NET_BIND_SERVICE=+eip path/to/caddy