Introduction: The need for Certificate AuthoritiesIn earlier articles, we have seen how digital certificates are one of the fundamental building blocks of Public Key Infrastructure (PKI). Certificates are used in multiple ways – for establishing identity, or for enabling secure web communication, or for proving ownership and integrity of software through code signing. However, the key question that arises is: while the certificate helps to establish the reliability of some other information (such as identity or proof of ownership for software), who vouches for the reliability of the information in the certificate itself? How does a user know whether a certificate can be trusted or not and whether the public key in the certificate actually belongs to the indicated owner? This is where a Certificate Authority or Certification Authority (CA) comes in. The CA is an entity that issues digital certificates, but does so only after performing a set of validations of the organization applying for the digital certificate – for example, confirming that the organization is the actual owner of the public key that will be included in the Digital Certificate. Examples of some of the well-known CAs include Comodo, Symantec, GoDaddy, GlobalSign, DigiCert, Let’s Encrypt, and Entrust. CAs are at the heart of PKI as a trusted third-party entity: they are trusted both by the certificate applicants, as well as the users (devices, operating systems, browsers) who receive the certificate and decide whether to proceed with the transaction or not.
Functions of a CAThe functions of a typical CA include receiving requests for digital certificates, processing these requests including performing background verifications of the applicants, approving & rejecting the requests, actually issuing the certificates, and managing and revoking certificates. These are explained below.
- Receive a Certificate Signing Request (CSR): The applicant who requires a digital certificate generates a public-private key pair and sends the public key to the CA along with basic information that is needed for the CA to issue the certificate.
- Process the information in the CSR: The CA processes the information in the CSR, including the type of certificate needed and the details about the applicant company. Depending on the type of certificate needed, the CA performs a set of validations, as described in the next section.
- Approve/Reject the CSR and issue the certificate: Once the validations are complete, the CA issues the certificate. The CA signs the certificate with its private key, providing a ‘seal of authenticity’ for the certificate and the public key of the certificate owner.
- Manage and Revoke certificates: The CA also manages certificates – for example, renewing expired certificates based on requests from certificate owners. In case the private key of a certificate owner is compromised, the CA can invalidate or revoke a certificate. Revocation helps to alert users that the certificate cannot be trusted anymore and helps to limit the impact from a breach.
Validations performed by a CAAny CA performs a set of validations before issuing certificates. The types of validations performed are:
- Domain Validation (DV): This involves checks to make sure that the organization (or person) applying for a digital certificate (for a domain) is the actual owner (or represents the owner) of the domain name. No identity checks are performed in this case.
- Organization Validation (OV): This includes additional checks (apart from domain name ownership verification) such as validating the organization itself and checking whether the applicant is authorized by the organization to apply for a certificate.
- Extended Validation (EV): This involves the highest levels of validations, including detailed vetting of the company applying for the certificate such as checking the registered name of the company, place of business, and other legal details.