Digital trust is increasingly a priority within organizations, and more broadly within society itself. Challenges surrounding data protection are at the heart of our everyday experience, making it crucial to take a closer look at public key infrastructure, better known as PKI. In concrete terms, PKI lets users communicate securely via a digital identity card known as a digital certificate.
These certificates have a limited lifespan and come with an expiry date, which raises issues around managing how they are renewed. Improper management of this process can impact heavily, resulting in problems like service interruption, which leads to financial loss (with e-commerce platforms becoming unavailable) and weakened brand image.
To prevent this, mechanisms like self-enrollment are put in place to empower clients to request new certificates themselves before the ones they are currently using expire. These self-enrollments are carried out via protocols, and in this article, we’ll take a closer look at one of them: SCEP (Simple Certificate Enrollment Protocol).
What is SCEP protocol?
Simple Certificate Enrollment Protocol (SCEP) is a simple certificate-enrolling protocol based on Hypertext Transfer Protocol (HTTP). It lets you automate deployment of X.509 certificates across network systems (routers, servers, phones, computers) in the context of existing public key infrastructure. SCEP is also widely used in MDM (Mobile Device Management) to enable self-enrollment across a network of mobile devices (such as phones and tablets), notably iOS devices that handle mobile device management (MDM), giving companies the opportunity to manage iPhone and iPad deployment across their entire organization.
How do I set up SCEP protocol?
Because SCEP protocol is underpinned by a client/server architecture or request/response model as well as HTTP protocol, setting it up involves two key entities:
- The client requesting the certificate
- The SCEP server, operating as an interface between the client and the Certification Authority (CA). This server authenticates client requests, sends them to the CA and issues the certificate signed by the CA. We’ll examine the different steps involved in client requests and server responses later in the article.
SCEP: how does it work?
So how exactly does an SCEP server work?
Let’s start by breaking down the steps inherent to the certificate enrollment process on the client side.
Assuming the client has already been issued the CA certificate(s) ahead of time, the first step involves checking the CA’s identity.
Once the CA has been authenticated, the client can start the certificate-requesting process by issuing a Certificate Signing Request (CSR) in PKCS#10 format. This request is then securely sent as an HTTP request using CMS (Cryptographic Message Syntax).
The request isn’t transferred directly to our PKI CA, but is sent to the SCEP server in PKCS#7 format, instead. The latter authenticates the certificate request using a secret shared ahead of time, or a self-signed certificate authenticated by the CA.
Once the client request has been authenticated by the SCEP server, the CSR request in PKCS#10 format is sent by the latter to the CA for processing. If the SCEP server sends back a CertRep message with PENDING status, the client enters into polling mode, sending a CertPoll (polling)message to the CA at regular intervals until the CA operator either approves or denies the request, depending on its policy.
When it comes to renewals, if the operation is handled by the CA and the certification authority’s policy permits it, a new certificate complete with new validity dates can be issued, even if the old certificate is still valid. The client will therefore need to use a RenewalReq message and sign it using the still-valid certificate.
The entire process can be visualized as follows:
SCEP: use cases
These days, SCEP protocol is generally deployed for different reasons:
- Drastically reducing administrative workload via certificate deployment and renewal.
- Simplified certificate authentication.
- Mobile device management (MDM): The rise of Bring Your Own Device (BYOD) policies now also means that SCEP is used to deploy certificates across a network of mobile devices (phones, tablets), notably for iOS devices that already support the protocol. In these cases, the enrollment process differs slightly, as you can see in the image shown here:
What are the keys to using SCEP protocol successfully?
- A well-configured network environment
- A functional, well-configured PKI
- An SCEP server that runs to RFC 8894 specs, meaning a server that incorporates the primary operations handled by the SCEP protocol: Distributing the certification authority’s public key, handling enrollment and issuing the certificate, renewing the certificate, handling certificate requests, CRL requests.
- Configuring client authentication on the SCEP server.
What are the limitations of SCEP protocol?
Based on the above, it’s clear that self-enrollment resolves many issues that crop up when managing certificates. But when an organization grows and is required to handle a sprawling network containing multiple internal and external public key infrastructures, the number of clients and therefore certificates that need to be managed rockets, and self-enrollment and the SCEP protocol become restrictive. This is where CLM (Certificate Life Management) solutions play a pivotal role. A CLM tool offers a number of services, including automated enrollment across a wide network of certificates.
What makes automated certificate management (CLM) solutions so instrumental?
For companies today, simplifying certificate-monitoring is vital. As we saw earlier, while automated certificate enrollment solutions are useful, they’re very restrictive when used alone. Pairing them with a certificate management tool like our BerryCert software is a game-changer: designed to support very large networks, BerryCert adapts to your own network, making it easier to sync and oversee all your internal and external PKIs, and operating as an SCEP server within your infrastructure. And if your CAs don’t support SCEP protocol (OpenSSL, for example), don’t worry: BerryCert acts as an interface between client requests and your various certification authorities, as illustrated here:
