You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Been using Let's Encrypt on a low-traffic server for a consulting project for a few years now. The validation only recently started failing, and after research it seems to be because we geo-block to US-only access. This seems like a reasonably standard scenario for a US-based company. The geo-block has been in place a long time, but it seems the Let's Encrypt service only recently started hitting our validation from non-US server and failing. For example, the validation worked perfectly in February, but failed in April with no changes on our end.
Describe the solution you'd like
Need a way to verify that only US-based servers will be used for validation request, so that we can maintain automatic renewal. Or some way to verify the source of the request originated from the Let's Encrypt server to allow it past the geo filter. Maybe a custom header that is provided by the client to compare?
Describe alternatives you've considered
I'm checking with security team if they are okay relaxing the geo-filter. I think we can disable the geo filter to do the renewal, but that is obviously not sustainable for automation. Also looking into the DNS-based verification, but the provider we are currently using (Network Solutions) is not on the list of DNS providers with automation.
Additional context
This is a simple project for a low-budget organization, with very low traffic generally only in a small local area. Let's Encrypt is an amazing solution for low-budget projects, but this restriction on world-wide geo access is a strange requirement for keeping a strong security perimeter around a very local project for a small company. I've already spent significant amount of their budget trying to figure out this issue, because the errors and troubleshooting is very difficult with issues like this. It's getting to the point that it would ironically be cheaper to pay for a non-free SSL certificate, which seems like a step backwards for Let's Encrypt.
Thanks!!
The text was updated successfully, but these errors were encountered:
ACME clients like win-acme have zero control over the Certificate Authority.
If you wish to continue using http validation (instead of DNS validation, which would not have the same limitations) you should either unblock all countries, blokc specific countries or allow all http /.well-known/acme-challenge/ requests.
General Let's Encrypt topics like this are best discussions on the Let's Encrypt forum https://community.letsencrypt.org/ and when discussed here should ideally be a Discussion, not an Issue.
Is your feature request related to a problem? Please describe.
Been using Let's Encrypt on a low-traffic server for a consulting project for a few years now. The validation only recently started failing, and after research it seems to be because we geo-block to US-only access. This seems like a reasonably standard scenario for a US-based company. The geo-block has been in place a long time, but it seems the Let's Encrypt service only recently started hitting our validation from non-US server and failing. For example, the validation worked perfectly in February, but failed in April with no changes on our end.
Describe the solution you'd like
Need a way to verify that only US-based servers will be used for validation request, so that we can maintain automatic renewal. Or some way to verify the source of the request originated from the Let's Encrypt server to allow it past the geo filter. Maybe a custom header that is provided by the client to compare?
Describe alternatives you've considered
I'm checking with security team if they are okay relaxing the geo-filter. I think we can disable the geo filter to do the renewal, but that is obviously not sustainable for automation. Also looking into the DNS-based verification, but the provider we are currently using (Network Solutions) is not on the list of DNS providers with automation.
Additional context
This is a simple project for a low-budget organization, with very low traffic generally only in a small local area. Let's Encrypt is an amazing solution for low-budget projects, but this restriction on world-wide geo access is a strange requirement for keeping a strong security perimeter around a very local project for a small company. I've already spent significant amount of their budget trying to figure out this issue, because the errors and troubleshooting is very difficult with issues like this. It's getting to the point that it would ironically be cheaper to pay for a non-free SSL certificate, which seems like a step backwards for Let's Encrypt.
Thanks!!
The text was updated successfully, but these errors were encountered: