Here's a draft for consideration for a new Documentation - Let's Encrypt page.
What if I can't allow incoming web connections from the whole Internet?
Sometimes a web site's (or a hosting provider's) security policies don't allow for incoming connections from the whole Internet. For example, they might allow connections only from a certain country that is the intended audience for a site, or block connections from countries that are expected to be unlikely to send much legitimate traffic. Or, if a site is meant only for internal use within an organization, they might not allow any connections from the outside world at all.
These policies can be a problem for Let's Encrypt's validation process. Before issuing you a certificate, Let's Encrypt has to check that you really control the domain names that you've requested to be listed in your certificate. The most-used methods for doing this involve making connections to your existing web site from all around the public Internet. These connections have to come from a relatively broad range of locations in order to improve security (which is called "multi-perspective validation"). The requests are already made from multiple different countries, and may be made from even more vantage points in the future.
As a matter of policy, Let's Encrypt does not publish a list of IP addresses from which these validation requests will originate. There are several reasons for this, but one important reason is to ensure Let's Encrypt has the flexibility to change these origins repeatedly in the future, according to operational needs and to stay ahead of attackers. The IP addresses of validation sources have changed before, and will change again, so we don't want anyone to make any assumptions about them.
What can you do if this is in tension with your security policy?
Do you actually need a publicly-trusted certificate?
If your certificate is going to be used only on an internal service within an organization (such as a corporate intranet), you might not need a publicly-trusted certificate. You may be able to use an organizational certificate authority instead of a publicly-trusted certificate authority. Doing this can let you skip the need for any form of external validation entirely.
This is usually feasible if all of the devices that are expected to consume the certificate are under common administrative control or ownership of the same person or organization, or if there are very few such devices so that it's possible to coordinate directly with all of their owners.
A certificate for personal use on a home network is also often in this category.
[probably need some advice or pointers on how to actually do that]
Consider using the DNS-01 method
The DNS-01 challenge method allows you to prove your control over a domain name by creating TXT records in the public DNS (as subdomains under your domain name). Unlike other methods, this does not require a direct inbound connection to your web service. For example, to prove your control of example.com in order to obtain a certificate for it, you can create a TXT record at _acme-challenge.example.com with a value provided to your ACME client software by the Let's Encrypt service. (This usually needs to be done every time that you request a new certificate covering that name, including during periodic renewals, so it's not a one-off process.)
You can do this effectively if you have a method to create DNS records automatically from software that is compatible with your ACME client.
If you don't currently have a way to do that, or if some of your DNS services themselves aren't accessible to the whole Internet, you may still be able to use this method by delegating authority for the _acme-challenge subdomain to a completely separate DNS service using an NS or CNAME record. This should not affect any other aspect of your DNS records, and should be compatible with a range of security policies that require limiting inbound connections to your services themselves.
[similarly, some advice or pointers on how to actually do these things!]
