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.
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:
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:
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.
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.