Troubleshooting Tip: Captive Portal does not work correctly when only 'HTTPS' is selected as a supported protocol

Description

This article describes why Captive Portal redirection fails or presents certificate warnings when only HTTPS is enabled. Redirection requires at least one intercepted request. When both HTTP and HTTPS are enabled, redirection works reliably. When only HTTPS is enabled, standard HTTP requests cannot be intercepted, and redirection uses the FortiGate’s untrusted certificate. Both protocols must be enabled for proper operation.

Scope

FortiGate, Captive Portal interception behavior, HTTP/HTTPS auth-type configuration, redirection reliability, certificate trust implications.

Solution

For a device to be redirected to the Captive Portal after connecting to the network, at least one of the requests the device makes must be intercepted by the FortiGate to tell the device where to go.

When both HTTP and HTTPS are enabled, this is not an issue. The device makes a regular HTTP request to its captive portal detection site, or when a user tries to browse to any website, and the FortiGate intercepts the request and redirects the user to the Captive Portal.

However, when only HTTPS is enabled, the FortiGate can no longer intercept regular HTTP requests.

Alternatively, configure the setting using the following CLI commands:

config user setting
    set auth-type http https
end

The user will still be presented with a redirect, but it will be encrypted using the FortiGate’s certificate, which is not trusted by the user’s device. The browser will redirect once the user proceeds past the certificate warning, but this behavior is not ideal.

Important note:

For redirection to work properly, both protocols must be enabled. The captive portal page itself will still be served over HTTPS.

Related article:

Troubleshooting Tip: General captive portal explanation, flow and troubleshooting of the 'walled garden'