# Certificate Lifecycle Handshake: Automate SCEP/PKI trust without user prompts In modern Unified Endpoint Management (UEM) architectures, the **Certificate Lifecycle Handshake** serves as a foundational mechanism for certificate-based authentication within Zero Trust environments. This document explains how **Hexnode UEM** enables **SCEP-based, automated certificate enrollment**, transitioning organizations from manual, user-driven certificate installation to a fully silent, OS-native identity model. By providing SCEP configuration policy aimed at 50,000 device fleet, Hexnode allows organizations to provision unique, per-device identity certificates at scale, without user prompts, manual CSR creation, or private key exposure. 1. Architectural Concept: “The Silent Trust Chain” -------------------------------------------------- The Certificate Lifecycle Handshake enables automated certificate provisioning without requiring end-user interaction. - **Mechanism:** The SCEP payload allows a managed device to generate a key pair locally and submit a **Certificate Signing Request (CSR)** to a SCEP endpoint. - **Administrative Configuration:** An administrator configures a **SCEP policy** in the Hexnode UEM console **(Policies > \[Platform\] > Security > SCEP)**, specifying: - NDES/SCEP server URL - Certificate Subject format - Key usage parameters - Challenge type (static password or Microsoft SCEP challenge URL) - **Enterprise Integration:** For on-premises deployments utilizing Active Directory Certificate Services (AD CS), Hexnode leverages the **Hexnode AD Agent** (also acting as the **Hexnode Cloud Broker**). This agent establishes a secure, outbound-only bridge between the Hexnode Cloud and the internal NDES server to retrieve one-time dynamic challenge passwords. - **Outcome:** The device generates its private key locally (software or hardware-backed depending on platform capabilities) and installs the issued identity certificate silently via the MDM profile. 2. Technical Handshake (Logical Flow) ------------------------------------- The SCEP workflow involves three entities: Hexnode UEM, the managed device, and the Certificate Authority. 1. **Policy Delivery:** Hexnode deploys a SCEP configuration profile to the device. This profile contains: - The CA’s SCEP URL. - The challenge password (static or dynamically generated). - The certificate subject definition. 2. **Local Key Generation:** Upon receiving the profile, the device generates a **private key locally** using its OS keystore (for example, Secure Enclave, TPM, or platform keystore). 3. **CSR Creation:** The device creates a **Certificate Signing Request (CSR)** using the locally generated key. 4. **Direct CA Communication:** The device connects directly to the CA’s SCEP endpoint (such as Microsoft AD CS via NDES) and submits the CSR along with the challenge password. 5. **Validation & Issuance:** The CA validates the challenge and certificate template permissions. If successful, the CA signs the CSR and returns the issued certificate directly to the device. 6. **Installation & Reporting:** The device installs the certificate into its system keystore and reports the policy execution status back to Hexnode, visible to administrators in **Action History**. 3. Configuration Matrix: SCEP Policy Parameters ----------------------------------------------- To ensure secure and automated enrollment, the following attributes must be configured within the SCEP policy. Hexnode UI AttributeConfigured Value / CapabilityReason for Automation & Security**Certificate Authority**Microsoft CA (AD CS) or GenericDictates the workflow type (Agent-based for AD CS vs. standard SCEP for Generic).**Subject**X.500 name format (e.g., CN=%devicename%)Uses wildcard shortcuts to ensure a cryptographically unique identity tied to the specific asset.**Challenge Type**Microsoft SCEP (mscep) URL or StaticDynamic challenge retrieval reduces exposure risk compared to static passwords.**Key Size**1024, 2048, or 4096 bitsConfigurable entropy limits supported natively within the Hexnode SCEP policy.**Number of Retries**Configurable (e.g., 0 to 30)Accounts for transient network drops or CA pending responses during the initial handshake.**Key Usage**Signing / Encryption / BothDefines usage extensions (e.g., Client Authentication, Secure Email) for 802.1X Wi-Fi or secure tunneling.4. Execution Logic: Certificate Lifecycle Management ---------------------------------------------------- - **Provisioning:** Certificate enrollment is triggered when an administrator uses **Associate Targets** to apply the SCEP policy to devices, device groups, or user groups. The device performs the handshake silently in the background. - **Renewal:** Renewal is governed by the certificate validity period defined in the CA template and the OS-level SCEP renewal handler. The device will re-initiate the SCEP process to fetch a new certificate as long as the Hexnode policy remains actively associated. - **Removal & Access Impact:** If the SCEP policy is **removed**, or the device is **disenrolled** from Hexnode, the associated configuration profile is removed from the device. On supported platforms, certificates installed via that SCEP payload are removed along with the profile. 5. Failure Modes & Diagnostic Reference ------------------------------------------- Common failure states during the SCEP handshake and their resolutions within the Hexnode ecosystem: Error SymptomSemantic MeaningResolution Path**404.15 Error (URL Too Long)**SCEP HTTP GET requests exceed default IIS limits.Widen the character limit in IIS settings on the NDES server to 65,534 to allow long SCEP payloads to pass.**Challenge Rejection**The static password expired, or the AD Agent sync failed.Verify that the Hexnode Cloud Broker is running on the server and successfully communicating with the AD CS.6. Governance: Removal, Revocation & Compliance --------------------------------------------------- - **CA Revocation:** CRL (Certificate Revocation List) or OCSP publication is handled entirely within the CA infrastructure. Hexnode governs certificate presence, not revocation lists. - **Zero-User Interaction:** Because SCEP certificates are delivered via trusted, system-level MDM profiles, the OS inherently trusts the payload. Users are never prompted to manually “trust,” “allow,” or input passwords for these certificates.