I set up Caddy a few months ago and it has been running without issue since then, however I was unaware that Letsencrypt institutes a limit of 5 certificates renewals per week per domain. Come last week I was unable to get a couple certificates renewed, so I removed a couple subdomains from my caddyfile and waited over a week to try running Caddy because of too many renewal attempts for my subdomains. After trying to run Caddy today I’m still unable to get my certificates validated/issued and am getting this info in my log:
“Unable to deactivated authorizations:”
“acme: Trying renewal with -189 hours remaining”
“too many renewal attempts; last error: acme: Error → One or more domains had a problem:”
I couldn’t find any info on the first one, that’s some strange wording indeed and not something I’d expect to find from LetsEncrypt.
The second one just indicates that the certificate has been out of date for 189 hours when the renewal was attempted. It’s not strictly an error, it’s just info. It would be there even if the certificate renewal were to happen at +30 days.
The third one is a precursor to an actual error detail, which you’ve left out, so there’s not much I can say other than one or more domains had a problem. ¯\_(ツ)_/¯
If you want to post the actual full error logs, we’ll be able to get you more information.
Sorry if I was too vague with the info I provided in the log. This is what it says in full:
2019/04/22 10:59:04 too many renewal attempts; last error: acme: Error → One or more domains had a problem: [mydomain.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol “acme-tls/1” for tls-alpn-01 challenge, url:
Ahh, the strange wording is from Caddy’s ACME provider, go-acme/lego. I’d never seen it before.
As for the unauthorized error, it looks like LetsEncrypt tried to connect to your server on port 443 but couldn’t negotiate TLS. Most likely indicates that the port doesn’t actually reach Caddy.
I’m kind of at a loss from where to go from here. Is there more information that I can provide that will be helpful? I’m not sure how Caddy can’t reach port 443 all of a sudden because I’ve had it working for months until I ran into this renewal issue. I haven’t changed anything regarding my configuration; I just restarted my computer last week and upon running Caddy I kept getting too many renewal attempts for 2 out of 7 of my subdomains. All that has changed configuration wise is that today I brought my subdomains down to a total of 5 in my caddyfile.
No, I just have one domain with 4 subdomains and none of them are working. I just created a new subdomain via cloudflare and put it in my caddyfile and removed every other entry, but I’m still getting ‘Unable to deactivated authorizations’ and ‘failed to obtain certificate:: error 403 :: Cannot negotiate ALPN protocol “acme-tls/1” for tls-alpn-01 challenge, url:’.
When you say terminating do you mean is cloudflare is causing the alpn challenge to fail? Or do you mean is Cloudflare handling the crypto settings for my site? If the latter then yes, I have SSL set to full (strict) and the minimum tls version to 1.0 (default). I haven’t changed anything with my configuration since it was set up and working though.
Is there some way for me to look into how Cloudflare could be causing this issue if you mean that Cloudflare is terminating the ALPN handshake?
Do you have your Cloudflare entries “orange-cloud” or “grey-cloud”?
When they’re orange-cloud, Cloudflare doesn’t actually respond to DNS queries with your IP address - they hide your origin server and direct visitors to themselves. Then, when a client connects to Cloudflare, Cloudflare connects to your origin.
This unfortunately means that when LetsEncrypt connects to the host indicated by DNS, they don’t actually talk to Caddy, so Caddy can’t solve the TLS-ALPN challenge - which takes place during TLS negotiation - because Cloudflare is actually negotiating TLS with the client.
You can check in your Cloudflare dashboard (for the orange cloud next to the DNS records), or you can dig your domain name and check whether Cloudflare returns your actual IP address or a pair of their own IP addresses instead.
Cloudflare is relatively unique in this offering, so I’ve written a bit in the past about the kind of issues that can pop up. See also: Infinite redirection - #5 by Whitestrake
Just to respond to this in particular - a while back, the challenge type used was effectively randomized (between HTTP and TLS-SNI). At some point TLS-SNI was discovered to be less secure, so it was deprecated.
TLS-ALPN was introduced as a replacement. Caddy’s ACME provider (acme-go/lego), when implementing TLS-ALPN, seem to have changed the challenge type behaviour to always use TLS-ALPN instead of randomizing which challenge to use.
In this way, updating Caddy may have “broken” your setup if you previously had it working with HTTP challenges behind Cloudflare.
Changing my domain and subdomains from orange-cloud to grey-cloud in my Cloudflare control panel solved the handshake/ALPN challenge issue and I was issued certificates so that Caddy is up and running again.
However, I’m struggling to get my configuration working using the caddy build with the cloudflare dns plugin. I have the tls directive set up specifying to use cloudflare in my caddyfile, and I set up my environment variables for windows by using my credential info and these commands:
setx CLOUDFLARE_EMAIL xxxxxxx@emailprovider.com
setx CLOUDFLARE_API_KEY myapikeyxxxxxxxx
Yet after restarting my command window to run caddy.exe I still get this error: 2019/04/24 16:20:32 Caddyfile:9 - Error during parsing: Setting up DNS provider ‘cloudflare’: cloudflare: some credentials information are missing: CLOUDFLARE_EMAIL,CLOUDFLARE_API_KEY
I should have tried this much earlier, but I thought logging off and back on would be enough, but all I needed was a restart to make the variables work. Thanks @Whitestrake for all the info and help you provided.