This article describes the effect that the ACME protocol can have on the results of network security scans. ACME is used to automatically request/renew certificates via 'Let’s Encrypt', and while it improves accessibility to proper/trusted certificates for web applications, it can also confuse when network security scans are performed.
FortiGate.
First and foremost, it is vital to consider how FortiGate utilizes the ACME protocol to generate a valid certificate:
FortiOS supports two forms of ACME challenge for 'Let's Encryp't: TLS-ALPN-01 (via TCP/443) and HTTP-01 (via TCP/80). By default, it uses the TLS-ALPN-01 challenge.
Have a look at the ACME RFC for TLS-ALPN-01 https://datatracker.ietf.org/doc/html/rfc8737
As per the RFC, the ACME TLS-ALPN-01 challenge requires the FortiGate to open an HTTPS port and listen for the ACME handshake, and it also requires it to generate and present a self-signed certificate on that HTTPS port.
Due to these RFC requirements, it is very common for security/network scanners like Nessus to flag this ACME listening port as a vulnerability/issue. The self-signed certificate that must be served on TCP/443 makes it impossible for the HTTPS connection to be 'proper' (i.e. using a valid certificate signed by a known Certificate Authority), and it also makes it impossible to implement HSTS (HTTP Strict Transport Security, which mandates that connections to this website must be proper HTTPS only).
It is also worth noting that Let's Encrypt and other ACME providers will ignore the untrusted aspect of the self-signed certificate since the TLS-ALPN-01 challenge does not require that the self-signed certificate provide a valid/trusted signature.
(see: https://datatracker.ietf.org/doc/html/rfc8737#name-acme-tls-1-protocol-definit).
If an exemption on the security scan cannot be made (i.e. the requirements of TLS-ALPN-01 are not considered acceptable) then as a workaround, the FortiGate can instead switch to the non-default HTTP-01 challenge to generate the certificate. The process to do so can be found in the following article below:
Technical Tip: Let's Encrypt failing to provision due to VIP configured on port 443
While following the above article, note that the HTTP-01 challenge is not encrypted and requires the FortiGate to open TCP port 80 and this can result in further security scan failures.
A detailed explanation of both the HTTP-01 challenge and the TLS-ALPN-01 challenge can be found in the following link:
https://letsencrypt.org/docs/challenge-types/
The key takeaway of this article is that using the ACME protocol on the FortiGate to obtain certificates from 'Let’s Encrypt' can result in security scanners flagging it as a vulnerability. In these, it is accurate to say that this is not a vulnerability but rather a misunderstanding of the security scanner (i.e. the certificate and the port open on the FortiGate are expected and required by TLS-ALPN-01).
References:
https://datatracker.ietf.org/doc/html/rfc8737
Technical Tip: Let's Encrypt failing to provision due to VIP configured on port 443
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.