Category filter
Implementing Certificate-Based Authentication for Passwordless Access
Certificate-Based Authentication (CBA) is the ultimate “No-Password” solution for infrastructure access. In this architecture, a device doesn’t connect to Wi-Fi or VPN using a username and password (which can be phished or shared). Instead, it presents a Digital Identity Certificate issued by your organization.
By linking your Identity Provider (IdP) to your Public Key Infrastructure (PKI), Hexnode UEM acts as the delivery vehicle. It silently installs a unique certificate into the device’s secure hardware. When the device enters the office or launches a VPN, the network hardware checks the certificate against the IdP/CA trust list. If it matches, the device is granted access instantly—zero touch, zero passwords.
1. Supported Platforms Matrix
Before configuring, ensure your target devices support the required payloads in Hexnode UEM:
- SCEP (For dynamic Identity Certificates): iOS, macOS, Android, Windows.
- Certificates (For static Root/Intermediate CAs): iOS, macOS, Android, Windows, Apple TV, Linux, visionOS, Zebra Printers.
- Wi-Fi Policy: iOS, macOS, Android, Windows, Apple TV, Linux, ChromeOS, Zebra Printers.
- VPN Policy: iOS, macOS, Android, Windows.
2. Technical Requirements
- Certificate Authority (CA): Microsoft AD CS (via NDES/SCEP), SCEPman, DigiCert, or a similarly supported PKI.
Note: A Root CA certificate must be pushed alongside the SCEP payload.
- Identity Provider (IdP): Microsoft Entra ID, Okta, or Google Workspace.
- Network Hardware: A RADIUS server (e.g., Cisco ISE, Aruba ClearPass, or FreeRADIUS) configured to support EAP-TLS.
3. Implementation Workflow
Step A: Deploy the Root/Intermediate Certificates
Before a device can authenticate, it must trust the server issuing the certificates.
- Navigate to Policies > New Policy > Create a fully custom policy (or edit an existing one).
- Select your target OS (e.g., iOS, macOS, Windows, Android) > Security > Certificates.
- Click Configure and upload your CA’s Root and Intermediate certificates (.cer, .pem, or .der format).
Step B: Configure the SCEP Payload (Identity Certificate)
Instead of a global setting, SCEP is configured directly inside the device policy.
- In the same policy, navigate to [OS Platform] > Security > SCEP.
- Click Configure and input your SCEP Server URL and Challenge Password/Secret.
- Define the Subject Name using Hexnode wildcards (e.g., CN=%name% or CN=%email%) to dynamically tie the certificate to the specific user assigned to the device.
- Set the Key Size to 2048-bit and specify the Subject Alternative Name (SAN) if required by your RADIUS server (usually the User Principal Name / UPN).
Step C: Automate Wi-Fi / VPN Configuration
Now, tell the device to use the SCEP certificate for network access.
- In the same policy, go to Network > Wi-Fi (or VPN).
- For Wi-Fi: Set the Security Type to WPA/WPA2 Enterprise (or Any Enterprise).
- Set the Accepted EAP Type to TLS.
- Under Identity Certificate, select the SCEP configuration you created in Step B.
- Under Trust, select the Root Certificate you uploaded in Step A.
- For VPN: Select your connection type (e.g., IKEv2, IPSec). Set Machine/User Authentication to Certificate and select the SCEP payload.
- Target & Publish: Go to Policy Targets, assign this to your “Managed Devices” or specific User Groups, and click Save.
4. The User Experience
- Onboarding: The user enrolls their device into Hexnode. During initial provisioning, the Root CA, SCEP certificate, and Wi-Fi/VPN profiles are deployed silently over the air.
- Connection: The moment the user walks into the office, the device handshakes with the RADIUS server via EAP-TLS and connects to the “Corporate” Wi-Fi without a single prompt.
- Always-On VPN: On supported platforms (like iOS and Windows), the VPN tunnel automatically establishes itself securely using the certificate, requiring no user interaction.
5. Security & Lifecycle Management
| Event | System Response |
|---|---|
| Certificate Expiry | Devices automatically request a certificate renewal from the SCEP server before the expiration date (configurable in the SCEP payload). |
| Device Lost/Stolen | The Admin executes a Wipe or Disenroll Device action in Hexnode. The policy is stripped, removing the Wi-Fi profile and deleting the certificate from the device’s keystore. |
| User Terminated | The IdP (Entra ID/Okta) disables the user. Directory sync updates Hexnode, which can automatically trigger compliance actions to revoke access and strip the device policies. |
6. Troubleshooting
-
“Authentication Failed” / Cannot Connect: Check the RADIUS server logs. The most common cause is the device rejecting the server because the Root Certificate was not properly deployed (Step A) or selected in the Trust section of the Wi-Fi policy.
Certificate Not Added to Device: Verify the SCEP gateway URL is externally reachable from the device’s current network. Devices need line-of-sight to the SCEP/NDES server to perform the initial certificate generation handshake.
Mismatched Identity: Ensure the wildcards used in the SCEP Subject Name (e.g., %email%) exactly match the username/UPN format expected by your RADIUS and IdP servers.
7. Audit Logging
Administrators can monitor the success of CBA deployments by checking:
- Hexnode Action History: Confirms the Policy containing the SCEP and Wi-Fi payloads was successfully associated with the device.
- Network/RADIUS Logs: NET_EVENT: Wi-Fi [Corp_Secure] authenticated via EAP-TLS Certificate [Thumbprint_XYZ] for User [j.doe@corp.com].