Cipafilter Captive Portal & Portal Certificate
Posted by , Last modified by Jose Urquiza on 17 May 2017 04:14 PM
Cipafilter Captive Portal
The latter feature is particularly useful for mobile devices accessing the network through an organization's "BYOD" (bring your own device) policy — by enabling the portal for these devices, you can ensure that mobile users are aware of your network usage policy and the need to trust your CIPAFilter's root CA for an optimal experience when SSL decryption is enabled.
Authentication is a key aspect of the portal system, but it is not required — by enabling the guest access feature, administrators can force users to the portal without actually requiring them to authenticate. This is useful if, for example, it is desired to show the network usage policy to all users.
The portal also provides an easy way for authorized personnel to re-authenticate with another account; this can be helpful if, for example, a teacher needs to use a computer which would otherwise be filtered according to the student policy.
Because clients are authorized by IP address, one user's authentication state can, in some configurations, carry over for the next user who accesses the same machine. One way to prevent this is to use the following log-out URL in a log-on script or as the client's default browser home page:
This URL immediately deauthorizes the client and then redirects the browser to the Web site specified by the optionalrequest variable (http://google.com, in this example).
Lastly, when SSL decryption is enabled, the portal's SSL guides (available at
The captive portal is SSL-encrypted (that is, it uses the HTTPS protocol) for security. Without this encryption, it would be extremely easy for anyone on your organization's network to view the traffic moving between other clients and the portal, and by inspecting that traffic, they would be able to capture the user names and passwords of anyone logging in.
To achieve protection from this sort of snooping, the portal must use a certificate. This certificate is in turn signed by a certificate authority (CA). By default, the CA used to sign the portal's certificate is the same one which is created in the SSL Configuration section.
However, this default configuration can be problematic:
The Portal Certificate feature provides a solution to all of these concerns, by allowing an organization to specify its own custom certificate, particularly one which has been signed by a trusted public CA.
To use the feature, enter the desired information into the Custom Certificate Information section. Much of this will be the same as what is entered under SSL Certificate Information. The Common Name field is of particular importance — it represents the site address that will be used for the portal when this feature is active. As an example, an organization with the domain myschool.edu may wish to use portal.myschool.edu as their portal's Common Name.
Once the certificate information has been entered, clicking "Generate Request" will generate a certificate signing request (CSR) for download. This CSR file is used by a certificate authority to generate the needed certificate file. Simply submit this file to the certificate provider of your choice, such as Namecheap or GoDaddy (Note: CIPAFilter does not endorse or recommend any particular certificate provider). Typically, one can expect a certificate suitable for this purpose to cost between 5 and 30 USD per year.
The certificate provider should respond with a public certificate and a CA bundle; once these are in hand, they need simply to be uploaded to the filter via the Upload Custom Certificate Data section.
It is also possible for an organization to use a wild-card certificate or one signed by an internally trusted CA, but this is not currently exposed to the Web interface. If you would like assistance configuring the portal this way, or if you have any other questions at all, tech support will be happy to assist you through the process.
Finally, whatever Common Name is chosen for the portal must have a record on or accessible to whatever DNS server (internal or external) the portal's clients are using. The recommended configuration is to point the custom domain to the special "bogon" IP address that the filter uses for the portal internally — this address is 192.0.2.1.