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.

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.

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.
  • The CA then 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.