Technical Tip: Configuring a shared FQDN and certificate for the Captive Portal without using a loopback interface

To use the same certificate for Captive Portals on different interfaces, they all need to share the same FQDN but resolve to the corresponding IP the FortiGate has for that interface.

This can be achieved in multiple different ways, the simplest would be to use a DNS filter.

The following is the first Captive Portal configured in the device. The certificate has 'captiveportal.lab.lan' as the domain (this should be a real certificate signed by a public CA). Currently, this resolves to 100.64.0.1 as per the local DNS database:

The following is the second Captive Portal configured in the device. Notice how the interface IP is 100.65.0.1, so the domain would not resolve correctly: 

In order to make this work, create a new DNS filter to 'block' captiveportal.lab.lan. When the DNS filter blocks a domain, it allows returning an arbitrary IP as the response. Under 'Redirect Portal IP', set this to the IP of the interface to go to. In this case, it will be 100.65.0.1:

For the first captive portal, the DNS setting should be set to use the FortiGate as the DNS server and the local DNS entry.
For every additional captive portal, the DNS should be set to Public DNS and the DNS filter applied on the policy.
When trying to use the 'DNS filter' option in the 'DNS Service on Interface' menu, the DNS filter is technically applied after the local entry is matched so it is not possible to use it in this way. It must be on a policy.

This configuration can be scaled to as many Captive Portals as needed. A different DNS filter would be used for each additional Captive Portal on its DNS policy.

When accessing the Captive Portal on Captive1, no certificate warning is seen:

When accessing the Captive Portal on Captive2, no certificate warning is seen: