| Description | This article describes how to configure certificates in FortiGate to avoid certificate warnings using captive portal in firewall policy. |
| Scope | FortiOS 6.0, 6.2 and earlier. |
| Solution |
When the authentication LDAP is enable into Firewall Policy, the FortiGate will trigger the Captive Portal authentication to user in order to get their user/passwords and validate it against the LDAP server.
By default FortiGate will use the port 1000 to authenticate HTTP and 1003 to HTTPS traffic.
# config system global set auth-http-port 1000
When FortiGate received traffic of unauthenticated user IP, the FortiGate proxied the connection and send a HTTP redirect to user browser, in order to connect to FortiGate internal IP to port 1000/1003 to authenticate.
For example, the unit debian-fortinet (192.168.81.101) does not belong to AD domain, but using LDAP authentication the device will authenticate against the LDAP server.
When the user in debian-fortinet browse to a site with HTTPS (i.e https://www.google.com), the browser will show the following error, since the FortiGate will intercept the connection and use the Fortinet_CA_SSL certificate to sign the certificate on the fly to google, so the browser will identify the as invalid since is not a public CA.
The FortiGate needs to intercept the HTTPS connections and impersonate the end site because needs to inject the http messages to redirect the connection to https://fortigate_ip:1003 to authenticate the user.
To avoid certificate warning in the browser during the captive portal authentication it is possible to apply the following procedure:
1)A DNS record is needed to fortigate_ip, because a valid certificate to that IP address will be necessary.
The fortigate_ip is the ipaddress internal of FortiGate, usually the default_gateway of the LAN's PC.
>nslookup captiveportal.markoz.local Name: captiveportal.markoz.local
2) A valid certificate with SAN issue by a public CA, a wildcard certificate (*.markoz.local) has been used, for lab purpose.
3) In LAB environment no access to sign the certificate with a Public CA, so a private CARoot has been created to sign the certificate of 2).
4) Import the wildcard certificate to FortiGate, the CRT and Private Key has been imported since the CSR and CRT was create external to FortiGate. If the CSR in FortiGate through the GUI is created, it is only necessary to import the CRT received from the CA Public.
5) Import the CARoot Private to FortiGate.
Note. If the wildcard certificate was issue by a Publica CA this step can be skipped.
6) Configure the FortiGate to use the following URL as captive portal.
# config firewall auth-portal
7) Configure the certificates as following, the wildcard will be used when browser connect to captiveportal.markoz.local, and the ca.crt.pem will be the CAPrivate certificate used to impersonate the first URL attempted on the browser URL.
# config user setting
Optionally in the auth-ca-cert it is possible use the default CAPrivate Fortinet_CA_SSL.
The Fortinet_CA_SSL is the certificate used on the deep-inspection profile of SSL/SSH Inspection, since all browser in the LAN must have installed it to avoid warning certificates during regular browsing when deep-inspection has been enabled on firewall policies.
The next time user tries to browse to a HTTPS site, the FortiGate will intercept the connection and will redirect to https://captiveportal.markoz.local:1003 to authenticated the user without a certificate warning.
Related link:
|
