Skip to main content

About Device Wifi & Certificate Based Authentication

What is it?

Certificate Based Authentication (abbreviated to CBA and previously known as device wifi) is a secure method used to verify the identity of users or devices when connecting to wifi networks.

How does it work?

Instead of entering a username and password to authenticate to a GovWifi network, a unique certificate is added to the user’s device (for example a laptop or phone). This allows the device to automatically log in to any GovWifi network close by.

Here’s a simplified breakdown of the steps:

  1. A network administrator generates a chain of public certificates. Copies of these certificates are uploaded to our RADIUS servers and the user’s managed device.
  2. When a managed device attempts to connect to the wifi network, it presents its certificate to the RADIUS authentication server.
  3. RADIUS verifies the presented certificate against those it has stored and challenges the user.
  4. If all verifications are successful, access to the network is granted.

Simple diagram of certificate based authentication showing a user's device connecting to a wifi network using a certificate

Advantages

  • Cryptographic authentication: When well managed, CBA is more secure than traditional password-based methods.
  • Eliminates the need for shared passwords: Against our recommendations some organisations share passwords and usernames between devices. Using CBA eliminates the need for this.
  • Automatic Login: Users can log in automatically without needing to enter passwords, facilitating a smoother user experience.

Disadvantages

  • Requires an organisation’s network administrators to have expert knowledge of PKI (Public Key Infrastructure) and CBA in order to generate and manage their certificates.
  • Requires additional work and knowledge from network administrators to set up and maintain the infrastructure behind CBA.

Infrastructure

Organisations that offer GovWifi can upload root and intermediate certificates via the GovWifi Admin portal. These are validated and copied to our RADIUS server from an AWS S3 bucket when the servers reboot each night. Below is a diagram and detailed explanation of the process, complete with links to code.

GovWifi CBA Architecture Diagram

Diagram showing the architecture of GovWifi CBA

An organisation uploads their root and intermediate certificates to our system via the GovWifi Admin portal. The certificates are always in PEM format.

  1. We validate the root certificate by checking the following:
  2. The organisation’s root and intermediate certificates are stored in the Admin database, in the certificates table.
  3. The certificate files are exported from the database, zipped, and then uploaded to an S3 bucket at 10pm every night. The export_certificates rake task is responsible for this.
    • Terraform for the rake task that uploads the certificates to S3 as a zip file:

    https://github.com/GovWifi/govwifi-terraform/blob/6887d90b4402a5d7f26f9cb018db73439155f502/govwifi-admin/scheduled-tasks.tf#L195-L235

    • GovWifi Admin code for the rake task:

    https://github.com/GovWifi/govwifi-admin/blob/d3e6b74be99cda12685abb615e44974f33c67ee9/lib/tasks/export_certificates.rake#L3

  4. When the RADIUS servers restart after midnight, the organisation’s certificates are copied to the ECS containers and stored in /etc/raddb/certs/trusted_certificates on the RADIUS server. This is done by a shell script that downloads the zip file, unzips it, and copies the certificates to the RADIUS containers.
    • The unzipping process adds an extra layer of error checking as it ensures all certificates are uploaded in their entirety.
    • If the zip file contains errors or is missing a certificate, new RADIUS containers will not be recreated and the containers from the previous night will keep running, preventing an outage.

We only allow certificates to authenticate to GovWifi if they are directly signed by a certificate provided by the organisation. This ensures that we only trust the certificate(s) explicitly intended for authentication. To enforce this, we upload only the leaf certificates of the chain.

For authentication to succeed, this approach requires compiling FreeRADIUS with the DX509_V_FLAG_PARTIAL_CHAIN flag, which allows the server to validate partial certificate chains. View the relevant code in the GovWifi Frontend Dockerfile.

CBA and the GovWifi smoketests

In order for the smoketests to work properly, they require two dummy TLS certificates to be generated. If you set up a new GovWifi environment, you will need to follow the certificate generation instructions.

How can organisations set it up?

Requirements

Organisations MUST have met the following requirements before they will be able to use GovWifi’s Certificate Based Authentication (CBA):

  • Organisations need to have set up Public Key Infrastructure (PKI) successfully on their systems and deployed it to managed devices. They should be comfortable with PKI and how to configure it. GovWifi can offer no support on this.
  • Organisations must have a plan in place for keeping their TLS certificates up to date and secure.
  • This Google Doc lists the detailed technical requirements that organisations should meet before considering CBA.

A note on GovWifi CBA technical support

GovWifi are unable to offer in-depth support regarding the set up of PKI or the generation and deployment of certificates. This should be done by an in-house expert. GovWifi’s role is to enable the CBA option on the Admin portal once requirements and risks are understood.

What does the GovWifi team need to do when an organisation wants to use CBA?

First make sure they understand the requirements.

Enabling CBA for new organisations

  1. Log in to the GovWifi Admin site as a Superuser. You should see the title “GovWifi Super User Administrators”.

    Screenshot showing the GovWifi Admin site as Superuser

  2. Select “All Organisations” from the list on the left.
  3. Select the organisation you want to enable CBA for.

  4. On the organisation landing page, scroll down and click the “Enable CBA” button.

    Screenshot showing the Enable CBA button

  5. The organisation’s network administrator can then log in and add their certificates via the “Certificates” menu. New certificates will not be uploaded to RADIUS until the nightly restart.

    Screenshot showing the Certificates section

Additional resources

Example set up of PKI (Public Key Infrastructure)

Below is a diagram of an example set up of PKI infrastructure integrated with Windows Active Directory. This is a rough guide for high-level planning.

Diagram showing an example set up of PKI infrastructure integrated with Windows Active Directory

Explanation of diagram

  • Standalone server: Stores the Root CA. This server should be highly secure and is only used to generate the self-signed root certificate.
  • Active Directory: Acts as a provisioning machine to install software and root certificates on end-user devices. It also sets up the wifi configuration and SSID (GovWifi).
  • Issuing CA: Used to install unique device certificates on each end-user machine to enable TLS connections.

In-depth instructions for Windows can be found in the GovWifi PKI setup and maintenance document (core team access only).

PKI Management Software

Organisations may use software such as Jamf, Microsoft Intune, or Entrust. Microsoft Intune can work with Microsoft Cloud PKI to manage certificates.
Note: GovWifi doesn’t offer support for third-party software.

More Information

This page was last reviewed on 24 January 2027. It needs to be reviewed again on 24 January 2028 by the page owner #govwifi .