Regards Rene ---
[size="1"]FCNSA.v5, FCNSP.v5, FCESP[/size]
Home: FWF60D FortiAP 220B Office: FWF60C, FWF60D, FGT110C, FGT200B, FortiManager, FortiAnalyzer, FortiAP 220B
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Here's the solution provided by FortiNet-Support, successfully tested on my FGT 500D with FortiOS 5.4.4:
- set a publicly trusted SSL-certificate under "User & Device" -> "Authentication Settings" which includes the common-name you wish to use (for example: captive.domain.com)
- create a public DNS-entry "captive.domain.com" which points to the internal IP of your captive portal.
- go to the CLI and enter the commands below:
# config firewall auth-portal
# set portal-addr captive.domain.com
# end
Now users will be redirected to https://captive.domain.com:1003 without any ssl-errors
Regards Rene ---
[size="1"]FCNSA.v5, FCNSP.v5, FCESP[/size]
Home: FWF60D FortiAP 220B Office: FWF60C, FWF60D, FGT110C, FGT200B, FortiManager, FortiAnalyzer, FortiAP 220B
Hello, I had a similar problem. I enabled secure authentication (HTTPS) through LDAP, to access a URL, for example: url.domain.com, the browser displays the alert invalid certificate. The problem was solved by buying a certificate for the sub-domain: url.domain.com. You can buy a wildcard certificate (* .domain.com) and can be installed on multiple servers. You will receive an SSL certificate and the intermediate certificate. You have up to seven days to test and return the money in case of failure. The steps were as follows: 1) System> Certificates> Local Certificates, I generate a new certificate. 2) Send the CSR generated certificate to the vendor. 3) It will return an SSL certificate and intermediate certificates. 4) Install the intermediate certificate in System> Certificates> CA Certificates. 5) Install the SSL certificate in System> Certificates> Local Certificates. 6) Use the options "auth-cert" and "auth-redirect-addr" in the firewall policy:
config firewall policyIt worked for my case and I hope it helps somebody else.
edit <policyID>
set auth-cert CustomCert
set auth-redirect-addr url.domain.com
end
I'm using the FortiOS version 5.2.2. URL for reference:
[ul]I can not tell what implications this type of configuration has security and what are the safe use of recommendations for certificates. Welcome to contribute.
Not knowing it was impossible He Dit It.
André Luiz
Since HSTS this is not only a warning anymore but full blocking of the access. The workaround now is to first surf to a HTTP website, to avoid the HTTPS to be activated, where Chrome would detect that it is not the original certificate.
With Chrome on a Windows PC, just typing "badidea" stops the HSTS from blocking further action. However I could not start this "badidea" on a smartphone.
I think we need a real solution to this, provided by Fortinet
No normal user will know to browse to a http site to bypass this issue without training, they will just come to us and say 'it doesn't work!'
Also its getting harder and hard to find a website that isn't redirected to https anyway, more than 50% of the web is HTTPS now - google is 77% https traffic
I totally agree with dbert84, we need a solution provided by Fortinet, simply saying to access an HTTP site first is not solution. I have a case exactly like this and the engineer's recommendation was this.
Here's the solution provided by FortiNet-Support, successfully tested on my FGT 500D with FortiOS 5.4.4:
- set a publicly trusted SSL-certificate under "User & Device" -> "Authentication Settings" which includes the common-name you wish to use (for example: captive.domain.com)
- create a public DNS-entry "captive.domain.com" which points to the internal IP of your captive portal.
- go to the CLI and enter the commands below:
# config firewall auth-portal
# set portal-addr captive.domain.com
# end
Now users will be redirected to https://captive.domain.com:1003 without any ssl-errors
Hi
this works well with only one subnet/interface
I want to use captive portal and redirection for LAN & Wifi (mode tunnel) on differents subnets.
I tried this
config firewall policy edit set auth-cert CustomCert set auth-redirect-addr url.domain.com endbut I'm still redirect to the one set here :
config firewall auth-portal set portal-addr captive.domain.comend
Edit :
If I unset global auth portal :
config firewall auth-portal unset portal-addr
each subnet is redirect to FGT IP interface, not to FQDN.
Test on 100D running 5.2.10
2 FGT 100D + FTK200
3 FGT 60E FAZ VM some FAP 210B/221C/223C/321C/421E
I got an answer by TAC :
Please note that these are two different and separate authentication methods. Captive portal takes precedence over any other authentication, therefore captive portal authentication is done first. Captive portal has two "modes": - Internal captive portal (hosted directly on the FortiGate) - External captive portal (redirect to external website => external website gathers login details of users and sends them back to FortiGate to verify) The internal captive portal uses either the interface's IP (default), or the FQDN configured in "config firewall auth-portal". => This is why you see the user traffic being redirected to "captive.domain.com" or the interface IP. Authentication redirection in a policy is only triggered when traffic matches this policy and authentication is needed. At that point, redirection to the URL specified in "auth-redirect-addr" happens. I hope that clarifies the situation. I would recommend to keep either the interface-captive portal, or the policy authentication-redirect, and remove the other. (if you want the FortiGate to redirect to the URL specified in the policy, make sure to remove the captive portal from the interface)
So I remove captive portal mode from interface, set auth-redirect on each policy, create dns entry for each
it's working for both LAN & Wifi without any certificate warning (I bought a multi-domain certificate)
2 FGT 100D + FTK200
3 FGT 60E FAZ VM some FAP 210B/221C/223C/321C/421E
Baptiste wrote:I got an answer by TAC :
Please note that these are two different and separate authentication methods. Captive portal takes precedence over any other authentication, therefore captive portal authentication is done first. Captive portal has two "modes": - Internal captive portal (hosted directly on the FortiGate) - External captive portal (redirect to external website => external website gathers login details of users and sends them back to FortiGate to verify) The internal captive portal uses either the interface's IP (default), or the FQDN configured in "config firewall auth-portal". => This is why you see the user traffic being redirected to "captive.domain.com" or the interface IP. Authentication redirection in a policy is only triggered when traffic matches this policy and authentication is needed. At that point, redirection to the URL specified in "auth-redirect-addr" happens. I hope that clarifies the situation. I would recommend to keep either the interface-captive portal, or the policy authentication-redirect, and remove the other. (if you want the FortiGate to redirect to the URL specified in the policy, make sure to remove the captive portal from the interface)
So I remove captive portal mode from interface, set auth-redirect on each policy, create dns entry for each
it's working for both LAN & Wifi without any certificate warning (I bought a multi-domain certificate)
Hi Baptiste, When you said you test it using WiFi, is it using Mobile Browser or Laptop Browser? Because I'm having the same problem, but the certificate issue only occurs using Mobile browsers. When I tried to access the SSID with Captive Portal using Laptop, the certificate issue doesn't occurs and it redirects me straight to the Captive Portal. But when I tried to connect to the SSID using Mobile device, I got an certificate issue before I got into the Captive Portal. Any thought guys? Regards
flex10 wrote:Hey there, thanks a lot that works really great!Here's the solution provided by FortiNet-Support, successfully tested on my FGT 500D with FortiOS 5.4.4:
- set a publicly trusted SSL-certificate under "User & Device" -> "Authentication Settings" which includes the common-name you wish to use (for example: captive.domain.com)
- create a public DNS-entry "captive.domain.com" which points to the internal IP of your captive portal.
- go to the CLI and enter the commands below:
# config firewall auth-portal
# set portal-addr captive.domain.com
# end
Now users will be redirected to https://captive.domain.com:1003 without any ssl-errors
I just wanted to add that you "don't" need to add a publicly resolvable DNS entry with your internal IP (i would say that this isn't security best practices and provide unneeded information outside) Here is what I've done in order to have only "internal" resolution on my portal FQDN mapped to a let's encrypt certificate:
config system dns-database edit "yourdomain.name" set domain "yourdomain.name" set authoritative disable set forwarder "internal DNS server or FortiGate or Forwarder" config dns-entry edit 1 set hostname "captive" set ip YOUR.INTERNAL.IP.ADDRESS (192.168.168.254 or whatever the captive portal is on) end
My certificate is mapped the captive.mydomain.name common name and is the certificate used in my user auth settings on the fortigate (as you've provided).
Thanks,
Kind regards,
Boris
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1558 | |
1033 | |
749 | |
443 | |
210 |
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.