I've recently been working to understand Let's Encrypt a bit better, and in particular to understand the different sorts of challenges (ie, ways of proving that you control a hostname) that they currently support.

(In general, Alex Peattie's A guide to creating a LetsEncrypt client from scratch has a great overview of the overall flow of the challenge process.)

Right now, there are three challenges; 'HTTP', 'DNS', and what is called 'TLS-SNI'.

• in the DNS challenge, you add a specific TXT record with specific contents (specified by Let's Encrypt) to your DNS zone, proving control over the DNS for the host that you want a certificate for. One of the drawbacks of this challenge is that DNS information doesn't necessarily update immediately, so it may take some time before LE sees your new DNS TXT record and can issue your certificate.

• in the 'TLS-SNI' challenge, you run a server on a specific port (currently only port 443, HTTPS) that has a self-signed certificate with a specific set of Server Name Indicator records; you can read the gory details in the ACME draft.

  The drawback of TLS-SNI is that it is difficult to handle the challenge through an existing HTTPS server (although not impossible). You'd basically need to configure a new virtual host for the special self-signed certificate you need to use for the TLS-SNI challenge, and it has a special magic name.

  As far as I know, the TLS-SNI challenge doesn't require you to be running a real web server on port 443. The challenge simply requires a TLS server that will return the special certificate.

• in the 'HTTP' challenge (the most well-known one), you put a magic file in /.well-known/acme-challenge/ on your web server and LE fetches it. At the moment the initial request from LE is always made via HTTP, but LE will accept a redirection to the HTTPS version of the URL so you can still do a universal HTTP to HTTPS redirection (I don't know if it verifies the HTTPS certificate in this case, but you should probably assume that it does).

  The HTTP challenge is the easiest challenge to satisfy without disrupting existing services, since you just need to serve a file at a new URL. General purpose web servers can usually do this without any reconfiguration at all; you just need a couple of new directories in the filesystem.

Under normal circumstances, only the DNS challenge can easily be done from a different machine than the one you're getting the TLS certificate for; HTTP and TLS-SNI both want to talk to the actual machine itself. However, if you're willing to play evil firewall games with port redirections, it's probably possible to satisfy HTTP and TLS-SNI challenges from another machine. You simply redirect inbound port 80 and/or port 443 traffic to the normal machine off to your challenge-handling machine, and then make sure you're running a LE client that is willing to cooperate with this.

I suspect that client support for HTTP challenges is higher than support for TLS-SNI. Thus if you only want to allow one port through your firewall to your target machine, the easiest one is probably HTTP. Note that there is no need to run a general purpose HTTP server on your machine to handle LE challenges; there are any number of clients that just run their own HTTP server for the duration of the challenge, including the official LE client.

In theory the TLS-SNI challenge could be extended to work against other TLS ports, such as IMAPS, POP3S, or SMTPS; this might allow your existing IMAP server or MTA to handle a LE challenge without needing additional ports opened or additional services running (some of the time) on the machine. In practice I suspect that this is not a Let's Encrypt priority and is unlikely to happen any time soon.

(It would also require SNI support in your IMAP or SMTP server, and having them reconfigured more or less on the fly to serve the magic TLS-SNI certificate to people who ask for the right server name.)