Technical Tip: How to allow Let's Encrypt traffic through the FortiGate to devices located behind the FortiGate

[pjang]

Description	This article discusses Let's Encrypt traffic (i.e. certificate request/renewal using the ACME protocol) and how it can be allowed to reach devices behind the FortiGate. There will also be some discussion regarding methods of hardening this access and limiting it to Let's Encrypt only.
Scope	FortiGate.
Solution	When connecting with Let's Encrypt (LE) and requesting a certificate using the ACME protocol, certain traffic flows need to be allowed for the operation to succeed: In the Outgoing direction (i.e. the webserver/device -> Let's Encrypt's servers), it is necessary to allow HTTPS (TCP/443) traffic. ACME uses HTTPS messages between the user and the LE servers for communication that is separate from the challenge traffic itself. In the Incoming direction (i.e. LE server -> the webserver/device), it is necessary to allow either HTTP (TCP/80) or potentially HTTPS (TCP/443) depending on what the Let's Encrypt user supports. TCP/80 is associated with the HTTP-01 challenge type, which is the recommended and most common challenge issued by Let's Encrypt. TCP/443 is associated with the TLS-ALPN-01 challenge type. See Let's Encrypt's documentation for more information on Challenge Types: https://letsencrypt.org/docs/challenge-types/. Allowing Let's Encrypt Traffic. For the Outgoing traffic, a simple Firewall Policy that allows the webserver/ACME Client to reach the Internet is all that is required. For Incoming traffic, it will be necessary to create a Virtual IP (VIP) or Virtual Server on the FortiGate as well as a corresponding Firewall Policy to allow traffic from Let's Encrypt to reach your webserver. This assumes that the webserver is not directly reachable from the Internet and requires incoming Port Forwarding/Destination NAT to be reached (i.e. the server has a private IP address). See the following links for general documentation on creating VIPs (either using Services or with individual port forwards): Virtual IP with services Virtual IPs with port forwarding If it is not desired to have an inbound Destination NAT then it is possible to use a simple incoming Firewall Policy to allow Internet access. If the webserver is meant to be accessed from the Internet then it is possible to already have incoming Firewall Policies, in which case it is possible to re-use the existing inbound policies. Notes on allowing TCP/80. Let's Encrypt's own Best Practice page suggests enabling TCP/80 access through the firewall (i.e. the FortiGate) for Let's Encrypt (see: https://letsencrypt.org/docs/allow-port-80/). Just to summarize the points in the previous document and add a few more: HTTP requests via TCP/80 can be redirected to HTTPS (TCP/443 or another custom port) on many platforms with web GUIs. This allows TCP/80 available for HTTP-01 ACME challenges while still ensuring that users of the web service are still upgraded to secure HTTPS connections. For example, the FortiGate and FortiClient EMS both have HTTPS-based web GUIs that support redirecting insecure HTTP requests to HTTPS instead. Incoming requests for TCP/80 in this scenario are just to satisfy the ACME challenge requirements, as ACME would utilize the HTTPS-based connection mentioned in the Outgoing direction for sending/receiving info related to the certificate request itself. Notes regarding inspecting/restricting ACME Challenges for security reasons. For the HTTP-01 challenge, it is possible to add additional protection by configuring a Web Application Firewall (WAF) profile on the FortiGate (or other appropriate product like FortiWeb) and applying it to the inbound Firewall Policy that allows TCP/80 traffic. More specifically, it is possible to create a WAF profile that enforces an HTTP Method Policy that only allows GET requests to GET requests to '/.well-known/acme-challenge/' (no quotation marks). /.well-known/acme-challenge/ is the directory that Let's Encrypt checks on the webserver (it uses a pseudorandom token string for each request). Restricting incoming HTTP methods to ONLY requests that contain this URL will significantly limit the access that outside Internet hosts have to the web server. The default ALL rule can be modified to block all other HTTP requests by setting the Allowed HTTP Methods to 'OTHERS'. Important: Do not apply SSL/TLS deep-inspection to TLS-ALPN-01 challenge traffic. Let's Encrypt sends a TLS Client-Hello towards the web server with the Application-Layer Protocol Negotiation (ALPN) header set to 'tls-alpn-01' and it expects a TLS Server Hello sent back by the webserver using a self-signed certificate that contains the acmeIdentifier extension. Applying deep-inspection on the FortiGate would result in the FortiGate disrupting the TLS-ALPN-01 challenge (since it will intercept the connection and present its certificate. Additionally, there is no benefit to deep-inspecting the TLS-ALPN-01 challenge, as the challenge itself is done at the TLS network layer (i.e. there is no content to inspect). Certain applications (such as the HTTPS-based admin web GUIs on FortiGate) may not be appropriate for Internet users to access, but it can be still desired to benefit from Let's Encrypt certificates served via the TLS-ALPN-01 challenge (i.e. HTTP-01 might not be an option). In those scenarios, it is recommended to change the HTTPS listening port used for admin web GUIs to something OTHER than TCP/443. This would allow TCP/443 inbound to meet the TLS-ALPN-01 challenge requirements without exposing access to a device's admin web GUI. Related articles: Technical Tip: ACME certificate with certificate management services other than Let's Encrypt on v7... Technical Tip: Let's Encrypt failing to provision due to VIP configured on port 443