Certificate enrollment refers to the process by which a user requests a digital certificate. They must submit the 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.
A certificate enrollment procedure begins when a user files 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 the user'sdomain name, a business telephone number that is obtainable via public sources, and the details for three contacts:
An authorization contact, or someone who is authorized to request certificates for your organization
A technical contact, or someone who receives an approved certificate and who will coordinate its renewals/updates
A billing contact who can manage purchases of certificates.
The CA may also request additional information based upon the type of certificate requested.
Besides submitting relevant information for verification purposes, a user 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. The user is usually not responsible for creating the public key themselves. As reported by Tech-FAQ, they send their certificate request to a Cryptographic Service Provider (CSP) installed on their 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, the user should verify the certificate, install it on their server, and make sure they make a note of its location so that relevant software like Apache can find it in the future. They should also consider copying the file received from Certification and storing a certificate's relevant keys in a secure location. Only then should they publicize copies of their 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. They then need to amass that information and use it to manage all certificate purchases and renewals.
That's where Venafi comes in. Our platform for machine identity protection 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 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.