Simple Certificate Enrollment Protocol (SCEP) makes certificate issuance easier, scalable, and secure. SCEP relies on HTTP and uses RSA cryptography. It lacks support for online certificate revocation, thus limiting its Certificate Retrieval List (CRL) support.
SCEP asks for the “challenge password” in the certificate signing request (CSR) shared between the user and server. Any MDM can push a payload containing the SCEP URL and the challenge password to the managed devices. It saves time and resources to enroll managed devices for a certificate individually.
How Does the SCEP Protocol Work?
The SCEP protocol follows these steps:
- Procures and validates the certificate from the Certificate Authority (CA)
- Obtains the certificate signing request (CSR) and sends it to the CA
- Dials the SCEP server for server certificate validation
- Re-enrolls to obtain new certificates before the current certificate expiration
- Recovers the certificate revocation list (CRL) via a distribution query
Click here for more on configuring SCEP for managed devices via SecureW2’s JoinNow Suite.
Why Do MDMs Use SCEP for Certificate Issuance?
Without protocols like SCEP, administrators may manually issue certificates from their Public Key Infrastructure (PKI) to devices. SCEP helps automate certification issuance, making enrollment and deploying certificates a breeze for admins. All a device needs is a URL and a secret key to enroll for a certificate through this protocol.
Popular MDMs like Jamf and Intune increasingly use SCEP to issue PKI certificates to the rapidly increasing number of mobile and smartphones on the network.
Is SCEP Enrollment for Devices on an MDM Secure?
Issuing certificates through SCEP is generally secure, but there are still opportunities to secure it even further. Because SCEP works by providing a URL and key to devices, anyone who gains access to that URL and key can enroll for a certificate. The user’s identity isn’t confirmed during the certificate signing request.
This means that an impersonator can act as a genuine user or device and acquire a SCEP challenge password to obtain a certificate for a different user or machine. He can gain access to a higher network level with malicious intentions or get another certificate than the originally intended one.
Are All SCEP Deployments Vulnerable?
For a SCEP deployment to be vulnerable, it must originate from an MDM that does not securely send the CSR through SCEP. Let’s examine the two most popular MDMs and their SCEP deployment:
Intune
Intune provides a secure SCEP deployment through an additional process called Intune CA partner integration. When a managed device goes to the SCEP URL and requests a certificate, that device is verified in Intune and Azure before the certificate being issued.
SecureW2 works with an Intune CA partner to create an Identity Provider (IDP) in our JoinNow management portal to help communicate with Intune. An identity provider supplies the endpoint URL to be added to the SCEP profile in Intune. The Certificate Authority (CA) is used here to configure the SCEP process.
Click here to know more.
SecureW2 allows the following options to integrate with Intune:
- Intune third-party CA partner
- Intune SCEP API token.
The SCEP API token connects an external SCEP-enabled CA to Intune. Still, a third-party CA partner is highly recommended as it is more secure. With a third-party CA partner configured in our portal, our PKI can confirm that the device exists in your Azure AD/Entra ID environment before issuing a certificate. Anyone who intercepts the SCEP URL and key illicitly can’t enroll for a certificate.
Additionally, the third-party CA partner functionality binds your Azure AD with your network for 802.1X security and allows for auto-revocation of certificates. Auto revocation of certificates ensures that unregistered users are kept at bay from joining your network once their certificates have expired or they have left the organization.
Jamf
Jamf Pro acts as a proxy communication server between the SCEP server and devices in an MDM. The proxy allows it to communicate directly with the server and install the certificates on the respective devices.
However, most MDMs still use the SCEP protocol to retrieve and deliver user certificates to managed devices.
What Are SCEP Security Best Practices?
To ensure a secure SCEP deployment, an admin should:
- Use a different Intermediate CA for each segregated group
- Use practical Security Information and Event Management (SIEM) software.
- Consider using ACME instead of SCEP for better certificate enrollment.
Use a Different Intermediate CA for Each Segregated Group
A two-tier trust chain with separate intermediaries for segregated groups provides more security as the primary and secondary CAs are kept separate. These are hosted on servers in different geographical locations to protect the primary CA’s private keys rather than the intermediate CA.
By doing so, if the intermediate CA comes under an attack or risk, it can protect the primary and other CAs as the attack would be contained to a particular intermediary.
Use Effective Security Information and Event Management (SIEM) software.
SIEM software helps an organization collate and analyze login details of all their digital assets from a single point. An admin can now recreate past incidents and put newer incidents into their purview for better judgment. A SIEM also helps investigate any malicious activity and implements stricter monitoring.
Use ACME Instead of SCEP for Better Certificate Enrollment
The Automated Certificate Management Environment (ACME) protocol has emerged as a pathbreaker in the certificate issuance arena. ACME supports clients by helping them place a CSR through HTTPS using JavaScript Object Notation (JSON) messages.
Prerequisites For SCEP Flow
A device must have an internet connection to receive the SCEP payload from an MDM. To begin with certificate enrollment, SCEP follows the following steps:
- A client requests a certificate from a trusted CA. The request is made for managed devices after creating a Wi-Fi profile, an SCEP profile, and a trusted CA.
- The CA authenticates a device after the key from the SCEP profile is provided.
- The CA signs and issues a certificate upon verification.
The managed devices are bound by an operating system that decides the enrollment course and certificate configuration. Also, remote and in-house deployments are other factors determining the course of certificate deployment.
Remote Deployment
Remote Deployment for Apple devices
For Apple devices, we recommend Apple’s Device Enrollment Programme (DEP), as it helps the MDM push profile logs automatically when a device tries to log in the first time. To push the profiles to the devices, a device first needs a Wi-Fi connection. Once it is connected to the Wi-Fi, the Apple server is pinged with the device ID, which verifies the device’s integrity through your MDM.
Remote Deployment For Intune Managed Windows Devices
If your organization uses the auto-pilot feature, they can seamlessly set up their Windows device at home. The user can connect to his home Wi-Fi, and the Windows server will verify the device with your MDM and issue a certificate. However, in the absence of auto-pilot, a user can auto-enroll for certificates by entering their Azure AD credentials into the machine over a call, where the organization can provide them.
Remote Deployment for Active Directory Managed Devices
As an organization that uses AD domain devices, you must configure your devices to join the local network through an established VPN tunnel. This ensures that the system and the domain controller are on the same network before they receive their certificates.
Remote Deployment For Chromebooks
Chromebooks work similarly to Windows and Apple devices by pushing the MDM profiles when a user logs in to the server for the first time with their device.
In-Office Deployment
If you don’t use the Apple DEP or Windows auto-pilot to onboard your devices, an onboarding SSID is necessary as it is the most secure alternative to onboard devices onto the network. An SSID can start with the “Organization Wi-Fi” or “Getting started”. If you are using SecureW2s JoinNow MultiOS, you should already be equipped with an onboarding SSID.
As we’ve helped set up hundreds of Onboarding SSIDs, we have a complete list of resources you should add to your whitelist, depending on the operating systems and infrastructure you have in your environment. This can be found in General > Documentation.
Seamless Certificate Management With SecureW2’s SCEP solution
SecureW2’s Managed PKI solution can integrate PKI and RADIUS infrastructures from all major vendors. This certificate-based network requires no combined forklift upgrades, allowing for a quick and efficient transition to a new, secure network. If an organization doesn’t already have a PKI and RADIUS, they can access SecureW2’s cloud RADIUS and PKI for efficient onboarding and authentication.
Jamf is SecureW2’s preferred Technology Partner, and they have excellent SCEP support and are widely used across the industry. SecureW2 also provides auto revocation of certificates through SCEP on Intune and JAMF, thus minimizing the effort of the admin to revoke expired certificates manually.
If you wish to continue using SCEP, our engineers will support all SCEP deployments through our JoinNow Connector PKI for seamless certificate management. At SecureW2, we are committed to bringing you effective zero-trust network architecture solutions.
Click here to explore groundbreaking network security solutions for your organization.
