Autocert (Let's Encrypt) and multiple services per machine?

<p>From the way I understand, autocert package needs port 80 open to perform http challenge, does it mean it is impossible to run more than one service on the same machine?</p> <p>Lets say there&#39;s one service listening on 443, and another on 8080. Both need certificates, but if first service already listening on port 80, then second service will be unable get its own certificate since port is already taken.</p> <p>Is there a way around it?</p> <hr/>**评论：**<br/><br/>mwholt: <pre><p>Autocert is nice for simple use cases, but doesn&#39;t handle advanced use very well. For more advanced ACME use cases like yours, use lego: <a href="https://github.com/xenolf/lego" rel="nofollow">https://github.com/xenolf/lego</a> - it allows you to wrap the ACME layer with your own challenge providers and customize the .</p> <p>But if you can just put a single service in front, and reverse proxy, that would be simpler. For that, you can use <a href="https://caddyserver.com" rel="nofollow">Caddy</a> (which uses lego), which can even coordinate ACME certificates in a fleet configuration very easily (just by sharing the same ~/.caddy/acme folder), so if you do need more than one instance or machine or container or whatever, they can all share the same certificates, and Caddy can reverse-proxy to your backend services. (I&#39;m biased of course, but this is still good advice.)</p> <p>(You could also configure the DNS challenge to avoid having the CA contact your server at all -- but autocert doesn&#39;t support the DNS challenge, you&#39;d have to use the underlying acme package or, as I recommended, use lego. lego&#39;s been around longer and has better support for DNS challenge.)</p></pre>tv64738: <pre><p>You can either front all your services with a single autocert instance, or use a name-based reverse proxy.</p></pre>tialaramex: <pre><p>Another option that may be applicable where several services have the same machine names is to issue certificates for the names once, but use the same cert (and associated private key) in all these services.</p> <p>This will not be appropriate for situations which prioritise security, as compromise of one service would get the private key that could be leveraged against the other services, but it may be simpler in some scenarios and often if everything shares a machine any security partitioning is pretty flimsy anyway.</p></pre>