Hi @robertgranholm, that’s LetsEncrypt telling you that they’ve rate limited your IP address because it keeps trying to make new accounts. It’s interesting that running Caddy manually has no problem. When you run it manually, does it serve any sites with Automatic HTTPS?
Unless you specify the environment CADDYPATH=/etc/ssl/caddy, when you run it with sudo caddy it will stash ACME assets in the /root/.caddy folder instead. So there might be an issue with the /etc/ssl/caddy directory. Although, the .plist has Caddy running as root:wheel, so it’d have to be something chronic (is the directory even there?).
Robert, I’m having trouble on mac, also. It all started for me last week or so… I forget now. Seems like it started right after I installed the 2019-003 high sierra security update.
You are getting the rate limits because caddy isn’t binding on the listen port but caddy keeps trying to renew.
I think my renewals had been failing for a while, but since the certificates were still valid, nothing was happening. but one of my domains was trying to renew with -1100 hours (that seems to me like it means that the cert expired 1100 hours ago. Since then, I moved the caddy working folder to a clean slate, and it fails ALPN for the first domain and the service fails.
I turned off “keep alive no matter what” so that I’d stop incurring a rate limit. I’ll try it again in the morning, but there is definitely something wonky happening on macOS with this.
If /root/.caddy is present, and sudo caddy just starts up with no issues running the same Caddyfile as the service, it means you’ve used Caddy as root from the command line before, fetched all the necessary certificates, and there’s valid TLS assets in that folder.
Meanwhile, if the Caddy service is trying to register a new ACME account, it means that /etc/ssl/caddy doesn’t have valid TLS assets (at least, Caddy can’t find a valid ACME account there). The fact you’re rate limited implies the service has been repeatedly trying to rectify this.
I’m not sure why macOS is having issues with Caddy-as-a-service-as-root accessing /etc/ssl/caddy. But since you’ve got working assets in /root/.caddy you could edit your .plist to point CADDYPATH to the latter instead, as a workaround in th meantime.
That’s interesting because I set up a blank install with its own caddy root (/usr/local/var/run/caddyshack2/) so it would force caddy to “start fresh” ( after @matt suggested trying to delete locks ) - caddy still failed.
My certbot commands from the command line (renewing certs for the macserver webapps) worked fine. That runs from /etc/letsencrypt or something like that.
So the folder permissions in caddy’s folders are fine and caddy was able to make root:wheel owned folders inside
This is expected. LetsEncrypt has rate limited you. Until the rate limit expires, or you use a different ACME provider, they will not allow you to make any new account requests.
Probably because an ACME account already exists for it. The issue, I’d wager, is that Caddy isn’t preserving your ACME credentials between runs, so it needs to make a new account every time. This is the usual reason for being new-account rate limited by IP address.
Aye, that’s the weird part about this escapade. Root shouldn’t care what perms or ownership is set.
whaere should I look to see how many accounts had been made? My old caddy folder was /usr/local/var/run/caddyshack and since then I’ve made the duplicate “fresh” folder of the same name but with a 2 appended.
caddy would place the locks folders and all that jazz in there. If I new what I’m looking for in the files, then I could see if the theory is correct.
I hesitate to think that is the case, though, because caddy had been running continuously for 4 months before beginning of the errors
Oh, actually, I’ve gotten confused. Sorry, I thought I was responding to the OP, who had the error:
2019/06/18 17:09:12 registration error: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:rateLimited :: Error creating new account :: too many registrations for this IP: see https://letsencrypt.org/docs/rate-limits/, url:
No reason why you couldn’t use /root/.caddy. The reason I suggested it was because you’ve already got a working set of TLS assets there - it’s about using the existing, rather than the specific location.
Minor nitpick: You probably mean ~/.caddy, not /~/.caddy (very different locations).
Glad you got it working.
Second LaunchControl. It’s pretty handy sometimes.