On June 3rd our deployment started failing its LetsEncrypt certificate auto-renewals with the following error:
CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d [example.com](http://example.com/):path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/119159274536, https://acme-v02.api.letsencrypt.org/acme/authz-v3/119159274546
This change did not correspond to any release deployment or change to our DNS settings. The domain is accessible from the internet, and looking at the failed authorizations it seems the acme check is timing out for some reason.
We deploy on DigitalOcean and use their DNS management with only A records (and recently added CAA records).
We are using meteor v2.7.3 and mup v1.5.8
Inside the mup-nginx-proxy-letsencrypt container I ran the force_renew command, but ran into my rate limit 😄. I'm guessing this will return return the above challenge error if I try again.
Are there any exposed mup CLI commands that can help troubleshoot this or run the force_renewal script on demand?
On June 3rd our deployment started failing its LetsEncrypt certificate auto-renewals with the following error:
CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d [example.com](http://example.com/):path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/119159274536, https://acme-v02.api.letsencrypt.org/acme/authz-v3/119159274546
This change did not correspond to any release deployment or change to our DNS settings. The domain is accessible from the internet, and looking at the failed authorizations it seems the acme check is timing out for some reason.We deploy on DigitalOcean and use their DNS management with only A records (and recently added CAA records). We are using meteor v2.7.3 and mup v1.5.8
Inside the
mup-nginx-proxy-letsencrypt
container I ran theforce_renew
command, but ran into my rate limit 😄. I'm guessing this will return return the above challenge error if I try again.Are there any exposed
mup
CLI commands that can help troubleshoot this or run the force_renewal script on demand?