Certificate enrollment refers to the process by which a user requests a digital certificate to use as a machine identity on a public-facing system, application, API, container or cluster. The process starts when you submit a certificate request with a certification authority (CA), an entity which issues and manages digital certificate for use within the public key infrastructure (PKI). Users can request a digital certificate from a CA manually or automatically without any interaction on their part.
Here’s a brief guide that includes the steps required for certificate enrollment.
A certificate enrollment procedure begins when you file a certificate enrollment request with a CA. The request should contain sufficient information to enable the CA to verify the identity of the user requesting the certificate. These pieces of data generally include your domain name, a business telephone number that is obtainable via public sources, and the details for three contacts:
The CA may also request additional information based upon the type of certificate requested.
Besides submitting relevant information for verification purposes, you must submit other details. For instance, the PKCS#10: Certification Request Syntax Specification, one of the most common formats for certificate enrollment submissions, requires users to send over their public key for the CA's signature, the digital signature, and the hashing algorithm used to create the digital signature. You are usually not responsible for creating the public key yourself. As reported by Tech-FAQ, you send your certificate request to a Cryptographic Service Provider (CSP) installed on your computer. The CSP, in turn, creates the public and private key pair for the request, adds the public key to the request information, and passes it on to the CA.
After receiving the enrollment request, the CA decrypts the digital signature using the public key, calculates a hash, and uses that product to verify the hash in the decrypted signature. It also uses all of the verification information provided by the user for validation purposes. For instance, it verifies that the requesting company is in good standing by confirming active registration in corporate registries and reaches out to the contact listed in the requester website's whois record to confirm the company's domain. If validation is successful, the CA digitally signs the public key, adds it to an X.509 certificate, and sends the completed certificate to the user.
At that point, you should verify the certificate, install it on your server, and make sure you make a note of its location so that relevant software like Apache can find it in the future. You should also consider copying the file received from Certification and storing a certificate's relevant keys in a secure location. Only then should you publicize copies of your certificate so that digital entities like web sites and browsers can authenticate it.
To maintain that authentication, users who purchase a certificate need to make sure they know all locations where certificates are installed and used by applications after enrollment. If you do not have an automated solution for machine identity management, you will need to manually gather and document that information and use it to manage all certificate purchases and renewals. If you lose track of a certificate that you have installed, it can expire and trigger an application outage. So, you want to take extra special care to keep track of all your organization’s certificates.
That's where Venafi comes in. Our Machine Identity Management platform features an enrollment portal that helps users configure multiple CAs. This allows organizations to more quickly request and renew certificates. But more importantly, the Venafi Trust Protection Platform allows organizations to verify that the certificate is installed correctly and will work as intended. The solution also features the ability to centrally generate key pairs and CSRs for users requesting certificates, and it enables dual controls for installation and enrollment.