What is Certificate Enrollment?

1. What is Certificate Enrollment?

Enrollment is the process by which users request CAs (Certificate Authorities) to provide them with x.509 certificates. There are multiple ways by which this is usually accomplished – both manual and automation (using certain protocols) – each with their own advantages. The enrollment process usually involves the CA signing the user’s key, and affixing it with an TLS certificate which can then be used to secure the user’s external-facing (or internal) systems.

1. What is Certificate Enrollment?
2. How is Enrollment Performed?
   • 2.1 Enrollment Procedure
   • 2.2 Post-enrollment Usage of Certificates
3. Enrollment Protocols

2. How is Enrollment Performed?

2.1. Enrollment Procedure

A typical certificate enrollment process involves the requester generating a key pair (one public, and one private key), sending only the public key to a CA along with a CSR (Certificate Signing Request), and then receiving a CA-signed public key and a TLS certificate which they can then install on an endpoint. Let’s take a look at how this plays out.

The CSR has to be sent to the CA in a certain format, which contains all the information a CA will need to verify the legitimacy of the requesting body. CAs are known for being very stringent with regards to issuing certificates to requesters only after they have been proven to be legitimate. CSRs usually follow PKCS #10 (Certificate Request Syntax Standard – developed by RSA), and include the following information:

• Public Key: The requester generates a key pair using a Cryptographic Service Provider (CSP) that is usually installed on their computer. They then send the public key to the CA.
• Digital Signature: The CSR is hashed using a hashing algorithm, and then encrypted with the requester’s public key, resulting in the formation of a digital signature.
• Hashing Algorithm: The algorithm used in the previous step is also sent to the CA in order for it to decipher the request. This adds an additional layer of security and authenticity.
• DN: The Distinguished Name of the requester, in order to verify identity.

The requester is also obliged to send other information pertaining to domain ownership and contact information.

The CA, once it receives a CSR from a requesting body, then has to verify the legitimacy of the requester using the information provided. Once it does so, it proceeds to carry out the key signing process, which is detailed below:

• The Digital Signature is first decrypted using the requester’s private key to ensure that the request has not been tampered with, in the time between the requester sending it and the CA initiating the signing process.
• Then, the CA uses the provided Hashing Algorithm and creates a hash of the request it just received (in other words, it creates a digital signature).
• If this new signature matches the Digital Signature provided by the requester, the CA takes it as proof that the request is valid, and moves onto the next step.
• The CA signs the requester’s public key and affixes it with an x.509 certificate.
• The signed public key and the certificate are sent back to the requester, completing the issuance process.

2.2. Post-enrollment Usage of Certificates

Once a requester obtains a digital certificate and a signed public key, they can install this certificate onto an endpoint, which, from then on, becomes a trusted network entity. It should be noted that the accepted best practice for certificate usage is to

As part of the standard TLS handshake process, any third party that interacts with the certificate owner will proceed to review the validity of the issued certificate by, once again, decrypting the digital signature provided by the CA (it is assumed that the third party possesses the CA’s public key in order to do this – the root CAs of leading CAs are installed on all major browsers).

The third party contrasts the decrypted has function against the has obtained by hashing the digital certificate. A match indicates that the certificate’s owner is truly the legitimate owner of the certificate. Then, the communicating third party can retrieve the public key from the digital certificate, validate it, and proceed to establish a secure encrypted connection.

3. Enrollment Protocols

In a world where every organization uses thousands of devices and hundreds of thousands of certificates with varying lifetimes, it is practically impossible to manually request every certificate, inventory it, and track it for expiry before renewing it (or requesting a new one). Several methods exist that allow for the simplification or automation of enrollment processes. For instance, Windows environments can leverage Active Directory Certificate Services (ADCS) to automatically push certificates to Windows Certificate Stores, without little to no manual intervention required.

There are also protocols that are used for enrolling certificates in different kinds of environments. The most popular ones are:

ACME (Automated Certificate Management Environment): By outsourcing an open-source agent to carry out certificate requisitions at set intervals, the ACME protocol allows for significant savings in terms of certificate management time.

SCEP (Simple Certificate Enrollment Protocol): This protocol is primarily used in places where certificate-based authentication is present in place of a password, in order to access services such as VPN. It is often used in conjunction with EMM (Enterprise Mobility Management) or MDM (Mobile Device Management) platforms in order to administer certificates to mobile devices.

EST (Enrollment over Secure Transport): EST is considered an upgrade over SCEP, and is more secure and refined than its predecessor. It used standard TLS as the transport security layer, and also uses ECC (Elliptical Curve Cryptography), and not RSA, resulting in smaller, more secure keys.