Guest Captive Portal HTTPS Redirection Loop on Apple iOS / Android CNA
Intercepting initial HTTPS probe traffic with a wildcard certificate (*.domain.com) causes Apple iOS Captive Network Assistant (CNA) and Android CaptivePortalLogin to trigger TLS mismatch security alerts, aborting the modal sign-in sheet and trapping guest Wi-Fi users in an unauthenticated redirection loop.
Technical Root Cause Analysis
Upon associating with an open or web-authenticated Wi-Fi SSID, mobile operating systems automatically launch a Captive Network Assistant (CNA) sub-routine. Apple iOS connects to http://captive.apple.com/hotspot-detect.html, while Android probes http://connectivitycheck.gstatic.com/generate_204.
When guest endpoints attempt modern web browsing or apps trigger background HTTPS requests, FortiOS intercepts TCP port 443 on the captive portal interface. To redirect the user to the captive portal logon URL (e.g. https://guest.corporate.com:1003/fgtauth?...), FortiOS must complete an SSL/TLS handshake for the intercepted domain.
If the certificate bound under config user setting -> set auth-cert is a wildcard certificate (*.corporate.com) or the default self-signed Fortinet certificate, the mobile device detects a Subject Alternative Name (SAN) mismatch against the intercepted domain (e.g., captive.apple.com). Because Apple and Android CNA security frameworks enforce zero-exception TLS verification for captive network detection, the OS immediately terminates the CNA modal window or displays ERR_CERT_COMMON_NAME_INVALID. The device never receives the HTTP 302 redirect, leaving the client disconnected from the internet.
Affected Firmware & Blast Radius Matrix
| FortiOS Branch | Vulnerable Builds | Confirmed Clean Build | Status & Workaround |
|---|---|---|---|
| FortiOS 7.2 | All Builds (7.2.0–7.2.9) | Configuration Profile Fix | Bind dedicated FQDN cert + enable HTTP redirect |
| FortiOS 7.4 | All Builds (7.4.0–7.4.4) | Configuration Profile Fix | Set explicit auth-portal-addr and DNS A-record |
| FortiOS 7.0 | All Builds (7.0.0–7.0.16) | Configuration Profile Fix | Exempt CNA HTTP probes from SSL interception |
Platform Impact: All FortiGate appliances managing wireless LANs (FortiAP) or wired guest VLANs running captive portal authentication for iOS, macOS, and Android devices.
Step 01: Free Verification CLI (Safe Read-Only)
Execute these diagnostic commands to inspect connected wireless station authentication states and check captive portal certificate bindings:
Diagnostic Commands
# 1. Inspect connected guest wireless station MACs and auth flags
diagnose wireless-controller wlc list-sta | grep -B 2 -A 6 "guest"
# 2. View active captive portal certificate and redirect settings
show user setting
# 3. Check active captive portal authenticated user list
diagnose user captive-portal-client list
# 4. Monitor wireless authentication controller events in real-time
diagnose debug reset
diagnose debug application cw_acd -1
diagnose debug enableRemediation & Workaround Steps (Teaser Preview)
Step-by-step remediation procedures available in the interactive Ferrite platform:
Frequently Asked Questions
Apple CNA and Android require seamless HTTP probe redirection. If the FortiGate intercepts HTTPS requests using a wildcard or self-signed certificate, the mobile OS halts execution due to strict TLS verification rules, suppressing the login modal sheet.
While HTTP probe interception should be used to trigger the initial redirect, credentials must be submitted over HTTPS with a valid certificate to protect user passwords from cleartext interception.
If auth-portal-addr is not configured under config user setting, FortiOS defaults to using the physical interface IP address, which generates browser certificate warnings.