Block untrusted clients on a guest network from issuing certificates


I host a small file server behind an nginx proxy that’s configured for HTTPS using Certbot for renewals. This proxy shares the same public IP address as our home and guests networks. How can I block untrusted clients on the guest network from issuing certificates using Let’s Encrypt for the domain name of the proxy?
Ports 80 and 443 on the public IP are configured to be forwarded to the proxy server by the router.



Let’s Encrypt currently allows two verification methods.
The first one requires that the server must correctly answer the challenge file. (I think that’s the one you are trying to control) and the other method is to add a challenge token to a specific dns name. (_acme-challenge.your_hostname)

For your question, Is there any possibility that the proxy server (that receive forwarding of port 80 & 443) could direct traffics to your guest devices? If you’ve setup that port 80 & 443 traffic are directed to a specific static internal address server (or device), there are almost no thing need to worry except some “experienced” guest controlled your proxy server / router…

Thank you


No, not as it’s configured

Guests are not allowed to even access the services provided by the server, what worries me is having someone issuing certificates from the guest network that later could be used to perform MITM attacks.
If what takes to complete the ACME challenge is to have ports 80 or 443 forwarded to the malicious guest, then I assume completing it would be impossible.


For how let’s encrypt validation designed, (currently) the server should be able to connect to port 80 initially, then could redirect to any other ports or domains (but not external IPs). if the guests can’t map your IP (public) 's port 80 to their device, there is no possibility that http-01 validation could be successfully performed.

In short: normally it’s not possible for them to issue a certificate on your behalf & within your guest wifi network.

Thank you


If you control ports 80 and 443, and DNS for, you have nothing to worry about. If “guest hacks my port forwarding” is in scope, in the future you’ll be able to use CAA records to further control issuance:

They’re not enabled yet, but the accounturi parameter would let you restrict issuance to your own account(s), and the validationmethods parameter would let you prevent usage of validation methods other than DNS-01. (If you use DNS-01.)


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.