Thanks Chris, > > I am using the following FQDN in the firewall rules: > > > > Letsencrypt_1 acme-v01.api.letsencrypt.org > > Letsencrypt_2 acme-v02.api.letsencrypt.org > > Letsencrypt_3 acme-staging.api.letsencrypt.org > > Letsencrypt_4 acme-staging-v02.api.letsencrypt.org > > > > But even when I allow 'any source' in the firewall rules still fails. > > > Yes, I would expect that to fail for 2 main reasons:
> 1. Unless the IP has a PTR bound to it AND the firewall is resolving IP > to PTR (it's not standard, and utilizes a fair amount of overhead) then > the rule is essentially meaningless for passing traffic. So you'd need > to use IP addresses instead of FQDN. Except... > 2. LetsEncrypt doesn't publish a list of IPs that would be used for the > http validation. They have arguable security rationale for this but > even so, since they're using a very large 3rd party CDN for that > traffic, they probably don't even have the ability to provide a list. > And if they did, the list would be enormous. Understood - although it has been working fine for months using those FQDN entries. > So long as you're allowing HTTP traffic to flow freely, there should not > be an issue with certbot polling and then receiving the verification > call from LE's servers. It seems that there must be something blocking > that HTTP traffic to get the verification done. So long as that's the > case, the automated renewals (and new requests, of course) will fail. But even when I allow all port 80 traffic in unmolested it still fails. I tried that before posting my query. Regards Colin _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
