Customization - Cipafilter Documentation

Manual - Customization

The Customization page provides the ability to customize the appearance and functionality of the captive portal and reject (block) page.

Although it is not required, all of the text fields on this page accept raw HTML.  Advanced users may wish to take advantage of this to add JavaScript or style sheets to the page, but even novice users can benefit from the text formatting options that HTML can provide.  Please also note that entering any HTML at all into this field will put the resulting text into a raw "HTML display mode"; so, for example, if a bold ( <b> ) tag is added, you must also add paragraph ( <p> ) or line-break ( <br /> ) tags to display paragraph breaks correctly.

General Customization

The Banner Image is an image displayed in place of the Cipafilter logo on public-facing pages.  The uploaded image should be in PNG format and should be designed to display cleanly at 96 pixels tall.  If older browsers (Internet Explorer 8 or below) are used in your environment, it is probably best to ensure that the image is exactly 96 pixels in height.  However, if these older browsers are not a concern, the image can be of any dimensions — it will be resized automatically.  One benefit to using an image taller than 96 pixels is that it will look crisp on high-resolution mobile devices.

Reject Customization

This tab contains settings related to the reject page — the page displayed when the filter blocks a Web request.

Reject Notice

The  Reject Notice  is a general-purpose message displayed on the reject page.  This notice can be used for any purpose; some organizations may wish to include a link or e-mail address through which users can request that a site be unblocked.  If no text is defined here, nothing is displayed in its place (there is no default).

Additional Reject Options

By default, the reject page displays text and a button offering users the option to temporarily whitelist the blocked site via the Whitelist Management feature and/or to log in to the captive portal if they are not already authenticated.  (Users must be authorized to access each feature and must always authenticate after clicking the button.)  The checkboxes under this section can be used to enable/disable this functionality where applicable.

Portal Customization

This tab contains settings related to the display of the captive portal.

Authentication Notice

The  Authentication Notice  is displayed on the portal whenever a user is required to log in.  This is a brief disclaimer which informs users that they need to enter a user name and password, and instructs them to contact their network administrator if they require assistance.  If your organization has a different process (for example, students must contact a particular teacher), you may wish to detail it here.  If no text is defined here, the Cipafilter default notice will appear on the portal; this should be sufficient for most organizations.

Acceptable Use Policy

If your organization has an acceptable use policy (AUP) or terms of service, the text can be entered in the Acceptable Use Policy field.  When present, a box containing this text appears on the portal.  If no text is defined here, nothing is displayed in its place (there is no default).

SSL Decryption Notice

An SSL Decryption Notice  is displayed on the portal whenever a root certificate has been generated via the Web Filtering page.  This is a brief disclaimer which alerts users that their secure (HTTPS) traffic may be subject to decryption.  If this field is left blank, the Cipafilter default notice will appear on the portal; this should be sufficient for most organizations.

Portal Certificate

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 on the Web Filtering page.

However, this default configuration can be problematic:
  1. The portal site will be accessible only from the address, which some organizations are uncomfortable with for security or branding reasons.
  2. The portal will display a security warning message to any user who has not yet trusted the filter's CA.  This message is unattractive and confusing.
  3. Some clients, particularly older mobile devices, won't display a warning at all in certain cases — the portal will simply fail to load entirely.
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.

Two certificate types are provided in addition to the defaults described above: Let's Encrypt and User-Provided .

Let's Encrypt Certificate

Let's Encrypt is a non-profit CA which provides a service through which anyone can obtain a publicly trusted SSL certificate, free of charge.  Furthermore, the Let's Encrypt certificate issuance and renewal process is designed to be largely automatic — once the option is enabled, the certificate will automatically and indefinitely renew itself.  This frees domain owners from the hassle of having to purchase and install new certificates to replace expired ones.

Due to this convenience and low barrier to entry, Cipafilter recommends the use of Let's Encrypt to provide the custom portal certificate.

As usual, a domain must be purchased and a public DNS entry set up (pointed to the public IP of the filter in this case) in order for a certificate to be issued.  One additional requirement of Let's Encrypt is that the portal must be accessible to the public Internet at all times, as Let's Encrypt's servers must be able to reach it in order to complete the certificate renewal process.

Having purchased a portal domain and set it up in DNS, the only information required to enable Let's Encrypt are the domain name and a valid contact address.  (Let's Encrypt will use this address to inform you of any important developments regarding the service.)  It is also recommended that the Let's Encrypt  subscriber agreement be reviewed in full prior to enabling the feature.

User-Provided Certificate

If desired, a certificate can be obtained through a more "traditional" provider.  This option is significantly less convenient than Let's Encrypt, but may be important to some organizations with existing infrastructure. In this case, the process is designed to work as follows:
  1. Enter the desired certificate information.  All fields are required except Organizational Unit .  See your certificate provider for details.
  2. Press Generate Request to generate a private key and download a certificate signing request (CSR).
  3. Provide the CSR to the certificate authority of your choice (for example, Namecheap or DigiCert ).  They will use the CSR to sign a public certificate matching the filter's private key.  The cost for this service varies wildly, from as low as 5 USD to as high as 1500 USD per year.  However, there are many low-cost providers that can be found online.  Cipafilter does not itself endorse or recommend any particular certificate authority.
  4. The certificate authority should provide a public certificate and usually also a "CA bundle" containing intermediate certificates for the authority.  Both of these files must be uploaded to the filter.
The active public certificate will be displayed in the box at the bottom of the page.

As with the Let's Encrypt method, you must configure your DNS to point the domain at your filter.  Alternatively, you can point it to the special "bogon" IP address that the filter uses for the portal internally — this address is
It is also possible for an organization to use a wildcard 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.
The redirect URIs for Google OAuth authentication may need updated when changing the filter's portal domain.

    • Related Articles

    • Manual

      This article provides links to the individual sections of the Cipafilter product manual.  A PDF of the Cipafilter product manual is attached to this article. Introduction Interface Conventions Installation Status Management Users Hot Spare ...
    • Manual - Portal

      The Cipafilter portal is a Web site that acts as a central point for Web-based authentication and SSL certificate installation. It can be accessed manually from any client which is proxying through the Cipafilter via; some users ...
    • Manual - Web Filtering

      The first thing to decide with regard to Web filtering is whether to run individual subnets in transparent or non-transparent (proxy server) mode. Transparent mode  — no client configuration is required, the Cipafilter simply intercepts all traffic ...
    • Manual - Introduction

      Cipafilter is a powerful routing platform capable of delivering an evolving tool set to protect your enterprise. Cipafilter's philosophy is to provide a cuing edge, well rounded, and aggressive network control solution to meet your current and future ...
    • Manual - Interface Conventions

      Most page/section headers, as well as certain option labels, within the Web interface can be clicked to produce the relevant section of this manual. Clicking a Save Changes button will cause the configuration options on any particular page to be ...