it says at the end "
The following settings are required to avoid certificate and security errors on the client. After the user is authenticated using the external captive portal, the browser redirects briefly to the firewall authentication portal over HTTPS. The browser then redirects the user to the original URL or a specific URL.
The specific URL needs to be configured in the Redirect after Captive Portal option in Create New SSID dialog.
config firewall auth-portal
set portal-addr <addr> #portal-addr setting must be an FQDN that resolves to the interface IP address of the guest SSID. The client must be able to resolve this using the DNS server configured in the DHCP scope.
end
"
This makes no sense? surely I need a public signed cert for the FAC for a guest to trust the portal?
This is an OLD cookbook at this point. I would use a newer version.
Why does this make no sense though? You do need a public certificate for guest clients. What exactly is your question?
There is no other cookbooks or documentation that specified this, I just assumed it was some sort of tunnelled http header as the FAC is trusted, My question you have more or less answered, I am guessing I need to create a CSR on the FAC, then get it signed by a public CA then import onto the FAC yes and select it as the https cert.
The article above, mentions setting a portal on the Fortigate, why would I do that when its the FAC that hosts the portal?
Because the webpage on FAC tells the client to post the credentials directly to the FGT. They are not posted to the FAC. I personally do not like the way FAC does this. I much prefer the way Cisco ISE handles captive portals. Aruba ClearPass also behaves the same way as FAC.
Created on 01-17-2025 12:54 AM Edited on 01-17-2025 12:57 AM
This redirection steps are a standard behavior for Captive portal authentications that uses HTTP redirection method. So the limitations comes from this type of configuration.
There are other solutions for Captive portal that use redirections based on DNS, like FortiNAC here, that will use portal login (redirect through DNS to a single portal page) and RADIUS MAC authentication in NAS.
As also shown in the workflow of the portal, there are two web pages that are presented to the end host. The FGT portal page is not usually visible because the redirection happens fast but in case there is a certificate issue the browser will complain. The end host should be able to validate both domains used in FGT and FAC captive portal pages.
so that means buying 2 extra public signed certs ?
Created on 01-16-2025 09:26 AM Edited on 01-16-2025 09:27 AM
Yes. Or a multi-SAN certificate.
I can arrange purchasing a cert for the FAC, but to get another public signed cert for a "quick redirection" seems like a really bad design to be honest. I assume, I can just use the hostname of the FAC in the cert when I create the CSR? I wanted to put the IP in as the SAN but I don't get that option on the CSR creation?
You can put both domains, for fgt and fac on a single certificate as SAN:
and use the same certificate on both FGT and FAC. If the certificate is going to be signed by a public root CA, it will not accept IP.
User | Count |
---|---|
2101 | |
1184 | |
770 | |
451 | |
344 |
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 2025 Fortinet, Inc. All Rights Reserved.