Table of Contents
- What is SCEP?
- Components of SCEP Gateway
- SCEP Device Enrollment Process
- How to Configure SCEP
- How Does SCEP Work with Windows?
- SCEP Certificate Device Wi-Fi Authentication
- SCEP vs EST
- SCEP vs ACME
- SCEP vs CMP and CMC
- Enrolling Devices For Certificates With SCEP Gateway and SecureW2
Distributing certificates to managed devices can be a monumental task with a lot of moving parts that need to be accounted for: PKI integration, establishing a gateway, configuration policies, certificate enrollment, device authentication, and much more.
Luckily, SCEP provides a solution to streamline the certificate enrollment process on managed devices so an administrator can automatically enroll every managed device for a client certificates without requiring any end user interaction.
What is SCEP?
Simple Certificate Enrollment Protocol, or SCEP, is a protocol that allows devices to easily enroll for a certificate by using a URL and a shared secret to communicate with a PKI. Mobile Device Management (MDM) software commonly uses the certificate enrollment protocol SCEP for devices by pushing a payload containing the SCEP URL and shared secret to managed devices. This can save an administrator a lot of time and effort compared to the alternative of manually enrolling their managed devices for certificates.
Components of a SCEP Gateway
Here, we will go over the core components in the SCEP gateway.
SCEP Gateway API URL
Simple Certificate Enrollment Protocol instructs devices how to communicate with the PKI, through the use of a Gateway API URL. Customers using SecureW2 can easily generate a SCEP Gateway API URL with our software. Then, they can put this URL in their MDM so it can send a payload to devices that should enroll for client certificates.
Certificate Authority (CA) and Certificate Template
Certificate Authority (CA) is the entity that is responsible for certificate management for a Public key Infrastructure (PKI) by playing an instrumental role in validating the identity of a user, device, or website before issuing digital certificates.
The most crucial step for SCEP to function optimally is validating the certificate authority (CA) that has issued the certificate. This ensures that the CA authority issuing certificates is trusted and that the entire certificate chain is secure.
SCEP requests for the CA certificate to validate important information such as the name of the certificate authority, the public key of the CA, the digital signature of the CA as a confirmation that the certificate has not been tampered with, the certificate serial number, and the validity period of the certificate to confirm it is valid and not expired. This information helps validate the integrity and authenticity of the certificate.
A certificate template is another important piece of the 802.1X ecosystem, as it contains the rules and policies that are applied when a CA issues a certificate to a client. A certificate template will also include important information, such as the cryptographic algorithms used, the validity period of the certificate, and the user role defined as per company policies to determine what level of access is to be granted to the client. The strength of your network, therefore, to a great degree, is dependent on the way your certificate template is designed.
With SecureW2, creating a certificate template is very easy and allows you the flexibility to customize the template to meet your needs as per your organization’s policies. Certificate template management of SecureW2 also gives you the flexibility to design the templates as per the requirements and attributes defined by the MDM that your company uses, as our solution is designed to integrate with all major MDM vendors.
SCEP Shared Secret
A Shared Secret is a case-sensitive password entrusted between the SCEP server and the Certificate Authority (CA). This shared secret verifies the CA with the right server for signing certificates. With SecureW2’s solution, the device presents the shared secret to our Managed PKI, and then the certificate enrollment happens on the device.
SCEP Certificate Request
Once the SCEP gateway is set up and the Shared Secret is shared between the SCEP server and CA, you can create and distribute a configuration profile that will allow managed devices to auto-enroll for certificates. The device will send a certificate enrollment back through the SCEP gateway to the CA. Once authenticated, a signed certificate will be deployed onto the device.
SCEP Signing Certificate
Most MDMs require you to upload a SCEP signing certificate, signed by the CA issuing certificates, that includes the entire certificate chain (signing certificate, Intermediate CA, Root CA). SecureW2 makes it easy to create a signing certificate in SecureW2. Just select the CA issuing certificates, and a PKCS12 file will be generated for you to upload into your MDM.
SCEP Device Enrollment Process
SCEP is the protocol that automates the issuance of a certificate to the client device by facilitating communication between the client machine or device and the SCEP Gateway provided by a PKI.
The SCEP device enrollment process is based on the HTTP for the request and response function and supports RSA cryptography. This certificate management protocol requires a secret or a password that is included in the certificate signing request (CSR) and is shared between the SCEP server and the CA to validate the device. The CSR also includes a SCEP URL that guides the device where it needs to connect to the API gateway to request a certificate.
Mobile Device Management (MDM) systems such as Intune, Jamf, and Workspace use SCEP to automate the process of PKI certificate enrollment process for both managed devices and unmanaged BYOD.
The process of device enrollment with SCEP can be broadly divided into the following steps:
- Request the Certificate Authority (CA) for its root certificate to validate the authenticity of the CA that is issuing the certificate to the client.
- Sends the Certificate Signing Request (CSR) to the CA to request a certificate for the client device.
- Performs server certificate validation to ensure the authenticity of the server.
Variations of SCEP
Simple Certificate Enrollment Protocol (SCEP) has multiple variations, each of which is designed to work with different operating systems. Though they vary slightly in terms of the process they follow, each one is designed with the core concept of automating and simplifying the process of device certificate enrollment for passwordless authentication. Here are a few examples:
Intune CA Partner is used with Microsoft Intune, a Mobile Device Management (MDM) and Mobile Application Management (MAM) provider. Intune CA is used for issuing certificates to devices managed by Intune, such as Apple, Windows systems, and Android devices. Click here for detailed configuration steps.
Jamf Proxy is used in conjunction with Jamf, an MDM provider that manages only Apple devices. With this SCEP variation, Jamf acts as a SCEP proxy and works differently than the traditional SCEP setups of sharing the SCEP URL and Key directly with the device, which then directly contacts the SCEP server. There are a few additional steps followed to validate the authenticity of the client by looking up client information on the identity provider. To learn more about deploying client certificates using Jamf Proxy, click here.
Microsoft Network Device Enrollment Service (NDES) is a Microsoft implementation of certificate enrollment protocol SCEP that issues certificates to devices without other Active Directory (AD) domain credentials from a dedicated certification authority (CA). NDES is used to issue certificates to network devices such as routers and switches.
ACME: Automated Certificate Management Environment (ACME), though not a variation of SCEP, ACME is included here because it functions in a similar manner to automate the entire certificate management cycle that includes certificate revocation, issuance, validation, and renewal. It is, therefore, often compared with SCEP. We will discuss ACME in detail in the later part of this article/document.
Certificate Re-Enrollment Process with SCEP
For seamless certificate lifecycle management, re-enrollment before the certificate validity expires is a necessity. When a certificate is due to expire, or the expiry date is approaching, there are two likely scenarios that occur. If the client certificate expiration date is earlier than the CA certificate validity date, the re-enrollment will happen through a renewal of the client certificate. However, if the CA certificate is due to expire before the expiration of the client certificate, the protocol then followed is rollover.
In case of renewal, when the certificate expiration date is approaching, before the expiry date (the date can be defined in settings), the client generates CSR and will follow the enrollment process using the current certificate to authenticate to the Certificate Authority. Once a new certificate is issued, the current certificate is deleted and replaced with the new certificate.
Rollover is done when the CA certificate is due to expire. The CA generates a “Shadow CA” certificate that becomes valid once the current certificate expires. The SCEP client requests for the CA for the “Shadow CA” certificate as it is required to generate a “Shadow ID” certificate for clients.
There are, however, a few MDMs, such as Meraki, Addigy, and Mosyle do not support auto-renewal.
Now that we have outlined how the SCEP device enrollment process works, as well as a few important concepts such as SCEP variation and re-enrollment with SCEP, let us look at how to configure SCEP.
How to Configure SCEP at a High Level
SCEP is designed to automate the certificate enrollment process and make it easier for organizations with MDMs. Below is a quick overview of configuring SCEP for MDM networks running on certificates using SecureW2’s JoinNow Suite, a cloud-based solution for managed devices.
Configuring your PKI and Building the SCEP Gateway
The SecureW2 Management Portal has the necessary components to deploy a SCEP Gateway with any major MDM. In less than 30 minutes, you can create the following:
Create a Custom Private Intermediate CA in the SecureW2 Management Portal.
Create a Signing CA, signed by the Intermediate CA.
Generate the SCEP Gateway API URL and Shared Secret.
Optional: Configure Custom Certificate Templates and Enrollment Policies.
Configuring SCEP in Your MDM
Now that we have all the components, it’s time to piece everything together to create the SCEP Gateway. Typically MDMs have a dedicated SCEP configuration section. Jamf is one of our favorite Technology Partners, and they have excellent SCEP support and are widely used across the industry. Below is an example image of where you can configure SCEP settings in Jamf. To learn more about how our SCEP Gateway integrates with Jamf, click here.
- Add the SCEP Gateway API URL
- Add the SCEP Shared Secret
- Upload the SCEP Signing Certificate
- Configure SCEP Payload that is sent to devices
- Specify which devices receive the Payload
- Optional: Configure Payloads for certificate application settings like Wi-Fi, VPN, Application Access…etc.
To learn more about how our SCEP Gateway integrates with MDMs, check out our Managed Device Solutions Page.
However, Jamf is different than other MDMs, so you will want to look into how your MDM supports SCEP. Below, we will share how all MDMs support SCEP and what are some unique ways each MDM supports it.
Configuring SCEP with Different MDM/EMMs
802.1x Certificate Via SCEP for Jamf Managed Devices
Jamf is unique in how it implements SCEP. It works as a SCEP Proxy and SCEP as a payload. A SCEP Proxy means all the requests from Jamf, and a SCEP Payload means all the requests come directly from the device. SCEP Proxies are ideal because the SCEP request between the Device and the SCEP Gateway ensuring that a hacker can’t steal the SCEP URL and Secret to issue themselves certificates. Jamf also supports certificate auto re-enrollment, which is nice when validity periods expire.
Besides that, the Jamf implementation is very standard. Click here to read how to configure Jamf with SecureW2.
SCEP Certificate Delopyement with Intune
Intune is unique in that it supports both a traditional SCEP implementation and a more advanced implementation that is called “Intune Third-Party CA SCEP.” Generic SCEP is also supported.
With the Third-Party CA configuration, there is an additional step after it is presented with the SCEP URL and the secret. Intune looks up the device information in Azure AD (Microsoft Entra ID) to ensure the device belongs to the organization and is active before the certificate is issued. This step helps address the security vulnerability of hackers intercepting the SCEP URL and secret and using it to get a certificate issued. It also allows certificates to be automatically revoked when a device is disabled or deleted.
If you’d like to read our documentation about how SecureW2 supports the Intune Third-Party CA SCEP configuration, click here.
SCEP Certificate Enrollment with Addigy
With Addigy, a custom mobile config is used for SCEP enrollment. This is less than ideal because it requires you to build all the settings you need rather than using the native settings available in the MDM. Automatic re-enrollment is not supported.
If you want detailed process steps, please click here.
SCEP Certificate Enrollment with Kandji
With Kandji, you can both configure SCEP with their UI, or by using a custom mobile config. When you use the UI there are advanced options, like certificate auto-renewal, which means you don’t need to push the SCEP Profile again when the certificate validity is about to expire.
For detailed steps, click here.
SCEP with Workspace One for SCEP Certificate Deployment
Workspace One MDM supports a Proxy, which improves security by relaying the SCEP requests to your PKI rather than having the request come directly from the device. It also supports Certificate Auto-renewal, which is convenient for admins.
Click here to read our documentation on how SecureW2 supports SCEP with Workspace.
How Does SCEP Work with Windows?
SCEP vs WSTEP
Developed by Microsoft, the WS-Trust X.509v3 Token Enrollment Extensions Protocol (WSTEP) has the same basic premise as SCEP; creating a secure connection between MDM and devices for sending data. While SCEP works for most MDMs, it does not work for Microsoft GPO. This is where WSTEP comes into play, as it’s the standard for auto-enrolling Active Directory Managed Devices with certificates. SecureW2 offers an easy-to-configure WSTEP Gateway API that many organizations use today for their AD domain-joined devices.
Integrating SCEP and Microsoft Intune
While Microsoft GPO may not natively support SCEP, Microsoft Intune can be configured to distribute certificates with SCEP. Through the gateway, devices can receive configuration profiles so they can request to enroll themselves for certificates.
Configuring Intune to work with SCEP is quite similar to how most MDMs use our SCEP Gateway API. Click here to see our integration guide for enrolling SCEP certificates on Intune.
SCEP Certificate Device Wi-Fi Authentication
For many organizations with MDMs, making sure each device is authenticated takes a lot of time and resources. SCEP automates the certificate enrollment process, so authenticating is streamlined. EAP-TLS is the standard authentication method for devices enrolled for SCEP certificates, because it’s the industry standard for certificate-based Wi-Fi authentication.
EAP-TLS Authentication Benefits
EAP-TLS is considered one of the best methods of authentication because it eliminates the need for credentials and doesn’t require any end user interaction. The device auto-detects the secure server through the SCEP gateway and can begin enrolling for a certificate immediately.
SCEP vs EST
Enrollment over Secure Transport (EST) is considered an evolution of SCEP because EST requires TLS client-side device authentication. SCEP uses the Shared Secret protocol and CSR to start enrolling certificates. Both EST and SCEP are great methods for automated certificate enrollment on managed devices, but the difference lies in whether TLS is used for authentication.
One thing to note, is that EST has seen a lot of market penetration with IoT devices. SecureW2 works with IoT manufacturers that don’t support EST or SCEP natively so that their software and devices can easily enable them in the software stack or custom deliver protocol options. Devices can then come either pre-loaded with certificates to customers, or customers can use SecureW2’s managed PKI to generate their own and enroll all their devices (IoT, BYOD, or Managed) for certificates.
SCEP vs ACME
SCEP and ACME, though are both used for certificate management they, do have some fundamental differences. Designed by Internet Security Research Group (ISRG) for their SSL certificate service, Let’s Encrypt, Automated Certificate Management Environment, or ACME, is a relatively newer protocol. ACME automates the entire certificate lifecycle management from issuance to renewal and revocation, eliminating the need to issue or renew certificates manually. With ACME, you don’t have to keep track of the renewal because once set up, and it will automatically initiate the renewal when the certificate validity is due to expire, thus saving a lot of work and resources that are otherwise involved with manual management of the certificate lifecycle.
ACME handles certificate issuance and certificate lifecycle management by setting up an HTTPS server using JSON messages. It requires an ACME client and an ACME server. You can use a certificate authority (CA) of your choice, provided it supports ACME. ACME can be deployed to automate domain ownership verification, CSR generation, issuance, and installation of certificates. ACME can also be used to enable Apple Managed Device Attestation (MDA), which is one of the main ways that SecureW2’s JoinNow Connector leverages the ACME protocol.
Apple designed Apple MDA to provide a higher degree of assurance about the devices at the time of authentication for certificate enrollment for better device trust. It allows devices to communicate with their Apple servers and get attested as genuine devices by prompting the device to use Secure Enclave, which stores unique identifiers such as serial numbers that are instrumental in validating the authenticity of the device. The diagram below shows the process flow of how ACME is used with JoinNow Connector and an MDM to distribute payload for certificate enrollment in conjunction with Managed Device Attestation.
To know more about how the process works, check out our blog on Apple Managed Device Attestation.
SCEP vs CMP and CMC
Certificate Management Protocol (CMP) and Certificate Management over CMS (CMC) are both similar to SCEP structurally, but handle different aspects of digital certificates. SCEP and EST mainly cover the enrollment and issuance of certificates, while CMP and CMC mainly cover certificate management, including revocation, status, and request.
SecureW2’s JoinNow solutions employ the SCEP gateway to distribute certificates, and the Management Portal allows you to manage issued certificates accordingly. The whole certificate process can be managed easily from anywhere.
How to Configure SCEP with SecureW2
SecureW2 allows you to easily configure SCEP for automating certificate enrollment and renewal. Below is a brief overview of the process steps:
- Configure the SCEP Gateway API in SecureW2. Use the Getting Started Wizard to generate a shared secret key and an access token.
- Create a new SCEP URL using the shared secret and the token. This SCEP URL will be pushed to your devices to enable auto-enrollment for certificates.
- Create Enrollment Policies as per your organization’s policies.
- Configure the Certificate Template for SCEP Gateway and insert the SCEP URL created in step two above. This is needed as it contains all the relevant information required for MDMs so they can configure themselves to be able to place CSR with SecureW2.
Using SCEP with SecureW2 solutions helps you automate certificate management with greater accuracy and ease to provide you with better network security by ensuring that every device on your network is equipped with a certificate.
Configuring SCEP may be complicated and may require a lot of time and expertise. With SecureW2’s PKI solutions, SCEP implementation is simplified by giving you the power to manage all your certificates from anywhere using a single Management Portal. SecureW2 works with IoT manufacturers that natively don’t support EST or SCEP to ensure their software and devices can be easily enabled in the software stack or custom-deliver protocol options.
Simplifying SCEP With SecureW2
Secure configuration of managed devices for WPA2-Enterprise is non-negotiable, but it doesn’t have to be difficult. Our powerful Gateway APIs allow you to use SCEP to enroll certificates to an unlimited number of managed devices in the same amount of time it takes to manually configure a single device. It’s the simplest and most secure way to provision certificates to all your devices.
Certificates will need to be distributed onto every managed device for certificate-based authentication to work, but it can be done quickly and easily with our SCEP Gateway API. Configuring a SCEP gateway may seem like a difficult task but SecureW2’s PKI Services allows for easy implementation. The SCEP Gateway API allows managed devices to silently and easily enroll for certificates on their own. Plus, our easy-to-use Management Portal allows you to manage the entire certificate lifecycle entirely, additionally giving you full visibility into the success of the certificate enrollment for fast and remote troubleshooting.
SecureW2’s JoinNow Connector offers organizations a turnkey Managed PKI Solution allows you to have greater visibility, control, and automation over the certificates issued within your network. It is designed to work directly with your cloud identities such as Azure, Okta, Jamf, or Intune, to ensure that PKI management is in line with your IAM policies. If you’d like to learn more, check out our pricing and contact us today.
