Certificate Authorities

Introduction: The need for Certificate Authorities

In 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 CA

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

1. 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.
2. 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.
3. 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.
4. 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 CA

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

Trust Hierarchies & Root Certificates

Each CA has a master certificate called a Trusted Root Certificate, which is the parent of all digital certificates issued by that CA and serves as the ultimate basis of trust in the CA itself. Root certificates are typically pre-installed in the device operating system and in browsers. Root certificates are used to create intermediate certificates, these intermediate certificates are used by the CA to actually sign the digital certificates being issued by the CA. This “chaining” of certificates to a parent going back all the way to the root certificate of that CA, is also known as a trust hierarchy or certificate hierarchy. This hierarchical approach is helpful to scale out PKI infrastructure overall – with a parent CA authorizing other CAs to issue certificates, by signing the root certificate of the other CA. Whenever needed, certificates issued by the other CA can be traced back to the root certificate of the parent CA.

CA Security

Since the CA and its root certificate are the foundation of trust for the entire PKI infrastructure, CAs need to have significantly higher levels of security as compared to any other organization. These include physical controls, logical controls, and the use of Hardware Security Modules (HSMs) for key management. In case a CA fails to meet or exceed the expected security standards, its root certificate could be removed from the system repository by browsers, operating systems, and device vendors. This will result in an immediate warning to the end user that the certificate for the current transaction cannot be trusted and is likely to influence the user to abort the transaction, resulting in an adverse business impact. To standardize the security requirements that a CA must adhere to, industry bodies such as the CA/Browser forum have been formed.

CA/Browser Forum

This is a voluntary group of CAs and browser vendors that have come together to form an industry body with the aim of developing guidelines for CA trust systems. This includes recommendations for validation procedures, key lengths, key management, and encryption algorithms. Two major guidelines from the forum include Baseline Requirements (BRs) and Extended Validation (EV) Guidelines. Baseline Requirements are the fundamental rules that any CA has to adhere to for issuing any type of digital certificate. EV guidelines provide additional security, technical and authentication requirements that a CA must adhere to in order to issue EV certificates.