Category filter
Automated Enterprise Certificate Management
Digital certificates serve as the “Silent Guardians” of your enterprise security infrastructure. For large-scale fleets like 500,000 devices or more relying on passwords for network access is inefficient and insecure. A robust Enterprise Certificate Management ensures seamless, password less authentication for Wi-Fi, VPN, and Email services.
This guide details how Hexnode UEM orchestrates SCEP (Simple Certificate Enrollment Protocol) and ADCS (Active Directory Certificate Services) to automate the issuance, and removal of certificates without user interaction.
The PKI Integration Stack
Hexnode functions as a “Certificate Proxy,” bridging the communication gap between your managed endpoints and your Certificate Authority (CA). To support diverse infrastructure needs, Hexnode offers two primary SCEP integration models across various device platforms such as iOS, Android, macOS: a dedicated Microsoft CA (AD DS) configuration and a Generic CA option for third-party PKI.
1. On-Premises Integration: SCEP & NDES
For organizations using Microsoft Active Directory, Hexnode integrates with the Network Device Enrollment Service (NDES) to securely issue unique certificates to devices.
- The Workflow: Hexnode communicates with your NDES server to request a challenge password. This password is sent to the device, which then generates a Certificate Signing Request (CSR) and presents the challenge to the NDES server to obtain the certificate.
- Security Validation: Every request is validated against a dynamic, one-time challenge password. This ensures that only managed, compliant devices can request and receive a valid certificate from your internal CA.
- Where the Private Key Lives: The private key is generated and held entirely on the device. Hexnode never holds, transmits, or has access to the private key at any point in the certificate lifecycle. The device presents only the CSR, built from the public portion of the key pair, to the CA for signing. Whether the key can be exported from the device’s keychain is controlled by the “Allow export from Keychain Access” setting in the SCEP policy, so key portability beyond the device depends on how that setting is configured.
2. Cloud PKI Integration: Generic CA (DigiCert, Entrust, GlobalSign)
For cloud-first organizations or sub-companies, Hexnode offers direct API integrations with third-party Certificate Authorities.
- Architecture: Hexnode connects directly to the cloud CA (e.g., DigiCert, GlobalSign) via generic path, bypassing the need for complex on-premises connectors. These CAs are configured under Generic rather than as individually named integrations.
- Scalability: This model eliminates the need to maintain on-premises NDES servers, allowing you to issue and manage certificates for 500,000+ devices entirely from the cloud.
- Where the Private Key Lives: The key’s custody works the same way here as it does with Microsoft CA (AD DS). The private key is generated and held on the device, and Hexnode never holds or transmits it, regardless of which CA option is selected.
Automated Lifecycle Management
Manual certificate management at an enterprise scale creates significant security risks and administrative overhead.
Instant Removal
Security is enforced dynamically based on device status.
- Trigger: If a device is marked as “Non-Compliant” in the Hexnode console.
- Action: Hexnode removes the policy, thereby removing the associated certificate. This instantly severs the device’s ability to connect to the corporate Wi-Fi or VPN, effectively quarantining it.
What’s Next: Linux Support
Certificate based authentication is coming to Linux. Hexnode is extending the same passwordless SCEP model that already secures iOS, Android, macOS, and Windows fleets to Linux endpoints.
Private keys will be generated and held on the device from day one, keeping Hexnode out of the key custody chain the same way it is today across every other supported platform. Initial releases will utilize secure, permission-restricted software keystores, with support for TPM 2.0 hardware binding scheduled in subsequent releases to lock private keys directly into the hardware layer.
For enterprises running mixed fleets, this means one certificate strategy, enforced consistently, regardless of which OS sits on the endpoint.
Core Use Cases
Implementing PKI at scale unlocks critical security capabilities for your fleet:
| Use Case | Description |
|---|---|
| Wi-Fi Authentication (802.1X) | Devices authenticate to the corporate SSID using a unique device certificate rather than a shared static password (PSK), preventing credential sharing and unauthorized access. |
| Always-On VPN | Certificates authenticate the device to the VPN gateway immediately upon boot, establishing a secure tunnel to the corporate network (VPC) without user intervention. |
| Email Security (S/MIME) | Deploy user-specific certificates to encrypt outgoing emails and digitally sign communications, ensuring data integrity and sender authenticity. |
Frequently Asked Questions
Does Hexnode have access to the private key during the SCEP enrollment lifecycle?
No. Hexnode operates strictly on a zero-private-key-exposure model. Across both Microsoft CA (AD DS) and Generic CA integrations, cryptographic key generation occurs locally on the endpoint (e.g., within a hardware-backed keystore or Secure Enclave). Hexnode acts solely as a SCEP transport proxy, routing the Certificate Signing Request (CSR), which contains only the public key, to the CA. The private key never traverses the network, nor is it accessible to Hexnode.
What cryptographic algorithms and key sizes are supported for SCEP payloads?
Hexnode supports RSA key generation, allowing administrators to enforce specific key lengths (e.g., RSA 2048-bit or 4096-bit) directly via the SCEP configuration profile. This dynamic configurability ensures that endpoint cryptographic operations remain strictly aligned with your organization’s internal InfoSec compliance mandates.
Can administrators restrict the cryptographic purpose of the issued certificate?
Yes. Administrators can define specific Key Usage (KU) parameters within the Hexnode SCEP policy. By explicitly configuring these attributes (e.g., restricting the key exclusively to digital signatures or key encipherment), organizations can cryptographically limit how the certificate functions on the endpoint, ensuring adherence to the principle of least privilege.
