omih-tir83mtz logo
omih-tir83mtz logo

All articles

Enterprise Wi-Fi Authentication and CertificatesUpdated 6 days ago

Audience

This document explains why we use Enterprise Wi-Fi with a private certificate authority (CA) in order to securely join client devices to our network. The audience should include any users who manage the settings on their own Wi-Fi client devices, IT admins who manage these settings on behalf of users, or at larger companies, Mobile Device Management system admins who understand the concepts and want to validate our design.

5S® Wi-Fi Networks

  • Primary tenant network: 
    • Name: Ice 5S Main
    • Security: Enterprise certificate-backed with per-user credentials
  • IoT tenant network: 
    • Name: Ice 5S IoT
    • Security: Per-device MAC allowlist, plus WPA2-AES preshared key
    • intended for tenants' devices that cannot handle username-based Enterprise security
  • Guest network: 
    • Name: Ice 5S Guest
    • Security: WPA2-AES preshared key which rotates weekly
    • intended only for transient guest devices

For more information, refer to the "Wi-Fi Networks..." help center article.


Enterprise Wi-Fi

The primary Wi-Fi network uses enterprise level Wi-Fi authentication to maximize user security. 

Like most Wi-Fi networks, we broadcast our network name in order to make it easy for users to locate and connect to it. This name is technically known as its SSID and is chosen to be user-friendly and consistent with the branding needs of the network owner and operator.

There is no authority regulating which SSIDs may be used by which organizations or in which locations. As such, nothing prevents someone from creating an unauthorized/conflicting network with the same name as ours. Someone might do this by accident, or an attacker might do it on purpose to trick users into connecting to the wrong network in order to intercept their communications or steal their credentials. An attacker could even spoof this network at other locations where targeted users are expected to travel, such as a nearby cafe where users might go for lunch. In such a case it is unlikely that we would ever be able to detect and disable the spoofed network.

To mitigate this type of network spoofing threat, we secure the network using WPA2-Enterprise security (and coming soon, WPA3-Enterprise), in which a digital certificate securely identifies the Wi-Fi authentication server and enables strong encryption on connections between Wi-Fi devices and the network.

Properly configured user devices will not automatically connect to such impostor networks. See "Validating Enterprise Wi-Fi Certificates" for details on properly configuring devices. In cases where users are expected to validate the certificates, these documents may be used as a basis for user training material. 

Public versus Private Certificates

The following sections discuss why the web uses public CAs, but our Enterprise Wi-Fi uses a private CA.

Public CAs and the Web

The web involves large and constantly changing sets of web sites and applications, users, and client devices. These parties typically have no practical way to directly share identity information in order to authenticate each other. So a system of third party authorities was created to perform this identity verification function.

These third party authorities are organizations known as Public CAs and will provide (for a fee) digital certificates that attest to the identity of a web site or application, or even users. These certificates have short lifetimes, currently limited to about 1 year maximum.

Public CAs must abide by rules defined by the CA/Browser Forum and pass their stringent audits in order to have their own digital certificates designated as trusted root certificates and pre-loaded into major operating systems like Microsoft Windows, Apple macOS, Apple iOS, Android, and Linux, or directly into web browser applications like Mozilla Firefox, Google Chrome, Apple Safari, and Microsoft Edge.

These pre-loaded Public CA certificates enable your web browsers and other applications on your computer, smartphone, or tablet to claim with high confidence that they are securely connected to a specific web site such as your bank, and that any communications with that site are secure and private.

If a Public CA violates the rules established by the CA/Browser Forum, then their root certificates may be invalidated in all the operating systems and browsers, which would cause the certificates they signed to become untrusted, and the web services protected by those certificates to stop working. Users would be upset, as would the web service operators who paid for those certificates.

One of these rules is that certificates must identify a formalized identity such as an Internet domain name, and can only be provided to a requestor who proves they ownership or control of that identity. Domain names are tightly controlled by a formal system of regulated Domain Name Registries and Registrars. Another rule is that digital certificates may have a maximum limited lifetime, currently about 1 year, after which they expire and can no longer be trusted.

Private CAs and Wi-Fi

Wi-Fi networks are significantly different from web services, and these differences make Public CAs less useful for securing Wi-Fi networks.

In most cases, Wi-Fi networks have local scope that can be measured in feet, sometimes miles. Identity information is normally shared directly between the operator and the users. Third party authorities are rarely useful.

Some Wi-Fi networks can arguably tolerate more risk than web services, because they generally provide short haul additional encryption on top of traffic that is already encrypted to the more stringent web standards.

Wi-Fi networks also have no central naming authority, and the names may be free-form and need not follow the format rules for Internet domain names. Wi-Fi network operators will often choose user-friendly SSIDs that fit their brand, school, or family identity or anything at all. The Public CA system can't authenticate ownership or even issue certificates that cover these free-form names.

Different types of Wi-Fi clients have a wide variety of procedures for validating Enterprise Wi-Fi certificates, many of which require the users or their company IT administrators to perform the validation.

Normally, organizations that operate an Enterprise Wi-Fi networks also operate at least one internal private CA, and directly control the Wi-Fi clients that are allowed to connect to the network. In such cases, adding a third party Public CA would likely reduce security. We are unaware of any Wi-Fi clients that currently require Public CAs, and doubt that clients will do so in future.

Most current Wi-Fi clients do not even consider whether the Wi-Fi network name matches the certificate subject when validating certificates. Even if a Wi-Fi network happens to use a valid Internet domain name and has a certificate signed by a Public CA, clients often ignore this. As such, there is no clear security advantage to using a Public CA certificate for Wi-Fi.

But there are still risks that need to be mitigated. Since anyone can spoof our Wi-Fi network and attempt to trick clients into connecting to it as a preliminary setup for attempting other types of attacks, it is important for us to give users a reliable way to authenticate to the Wi-Fi network.

Based on these requirements and considerations, we have chosen to use certificates generated by our own private CA, and distribute the certificates through our support portal. Please see "Validating Enterprise Wi-Fi Certificates" for our certificates and detailed instructions.

Was this article helpful?
Yes
No