Technical Tip: Let's Encrypt failing to provision due to VIP configured on port 443

[mdibaee]

Description	This article describes how to force FortiGate to fall back to port 80 for the ACME certification assignment.
Scope	Having a VIP on TCP port 443 and using the same public IP as the one to which the ACME certificate domain is resolved to.
Solution	By default, when using ACME, the challenge is sent via TCP port 443. If a VIP is in use on this port, then the incoming ACME challenge will be processed by the VIP rather than the system/ACME daemon and therefore the process will fail. This problem can produce debug outputs such as the following error: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, problem: urn:ietf:params:acme:error:unauthorized However, if TCP port 443 is in use by a process on the FortiGate (e.g., HTTPS daemon, SSL VPN daemon, etc.), the ACME daemon will fall back to port 80 for the challenge. One way to achieve this with minimal impact is to set the FortiGate’s system telnet port to 443 as telnet is not typically used by administrators. This can be configured by navigating to System -> Settings in the GUI: Make sure that telnet is not allowed on any interface of the FortiGate for administration unless it is desired. Note that: If telnet is being used to manage the FortiGate, it will no longer be able to do so on the external interface for the configured VIP on TCP port 443 as such traffic is processed by the VIP as mentioned earlier. If there is also a VIP configured using TCP port 80 and using the same public IP as the one to which the ACME certificate domain is resolved, this workaround will not function. To achieve this configuration using the CLI: config system global     set admin-telnet enable     set admin-telnet-port 443 end