A certificate authority (CA), also referred to as a certification authority, is a trusted entity that validates the identities of online assets, such as websites or email addresses, owned by organizations through the issuance of electronic documents called digital certificates. CAs validate domain ownership and, in some cases, the legitimacy of website ownership and then issue digital certificates that are trusted by web browsers like Chrome, Safari, and Firefox. They play a pivotal role in keeping the internet safe by encrypting online communications and reinforcing trust.
Before diving deep into the subject of CAs, it's important to understand the basic functioning of an SSL/TLS certificate and its role in securing online communications.
An SSL/TLS certificate is a cryptographic file installed on your web server that helps establish secure, encrypted online communication. SSL/TLS certificates serve two major purposes:
When you connect to a website over HTTPS, the exchange of information is encrypted and becomes undecipherable for cybercriminals who try to eavesdrop.
SSL/TLS certificates work based on a trust relationship framework (usually called the "chain of trust") where they're signed and issued by trusted CAs. As stated above, the CA is responsible for validating the domain identity and issuing, retaining, and revoking certificates for the particular domain to ensure a secure platform for users to connect and share their information.
You can view the SSL/TLS certificate details of any website that runs on HTTPS, and you'll find the following information:
Details on which public key and the corresponding cryptographic algorithm are used to sign the certificate.
Information about the domain the certificate was issued to or, for certain types of certificates, the legitimacy of the organization operating the website.
The signature of the trusted issuing authority that reaffirms the security of any information shared with the website.
The time period until which the specific certificate is valid. Every SSL/TLS certificate comes with a set validity period.
All this information can be obtained by clicking the padlock 
in the address bar of the website that you want to learn about.
When a user connects to a website via HTTPS, both communicating parties—the client machine and the server—validate one another's identity and authenticate each other prior to establishing a connection. This process is called a TLS handshake. During this process, a session key is generated, which provides symmetric encryption of the particular session after both parties have successfully authenticated each other.
Here is the sequence of steps that occur in the background when a user connects to a website over HTTPS:
Certificate chain of trust is an important concept in public key infrastructure (PKI) that helps trace an SSL/TLS certificate back to its root certificate, i.e., the issuing CA with which it was signed. Between a certificate installed on a web server and its root, there's usually one or multiple intermediate certificates linked with one another. Browsers require complete information about the chain of trust to determine whether a website's certificate can be trusted or not, so it's important for organizations to make sure that the trust chain is intact for the certificates installed on their websites to comply with browser requirements and to instill trust among site visitors.
There are three significant components in the certificate chain of trust. They are:
A root certificate lies in the top most position of the chain of trust hierarchy. It's a self-signed certificate signed by an issuing authority and adheres to the standard of an X.509 certificate. A root certificate signed by a public CA is trusted by default in the client browser's trust stores. If the private key of the root certificate is compromised, all the certificates signed using the root are affected and need to be replaced. Therefore, a root certificate authority must keep a close watch over its private key and refrain from signing end-entity certificates directly.
An intermediate certificate functions as the middleman between the root and server certificates. Usually, there's at least one intermediate certificate present in the chain of trust. The main purpose of an intermediate certificate is to keep the root private key safe and offline and prevent it from directly signing server certificates of end entities that are exposed to potential cyber risks. While a root certificate is trusted by default by client browsers, an intermediate certificate isn't always shipped along with client OSs, browser trust stores, or other certificate-aware applications.
Server certificates, or end-entity certificates, are installed on web servers and authenticate the identity of their local hosts. When installed on a website, the hypertext transfer protocol is switched from HTTP to HTTPS (where S stands for SSL), indicating an encrypted connection link between the server and the client browser. Server certificates deployed to public facing websites are usually signed and issued by trusted CAs. If the server certificate for a particular website isn't issued by a trusted CA, then the client browsers fail to trust the website, resulting in security warnings eventually eroding the credibility of the brand among prospective customers.
There are five broad categories of trust models within the PKI realm. They are:
In this model, all user certificates are directly issued by the CA present in the chain. The chain of trust begins with the CA and ends with the server certificate with no intermediate certificate involved. This configuration is simple to deploy, but if the CA's private key changes, the entire architecture must be reconfigured. For this reason, this model isn't suitable for larger communities of users.
The hierarchical model, also known as the tree model, is the most commonly adopted method for implementing PKI. In this configuration, the root CA, or the trust anchor, occupies the top-most position of the trust chain and the trust relationships are unidirectional (from top to bottom). This model accommodates one or more intermediate CAs and is scalable, and every end-entity certificate is traceable back to a single CA, i.e, the root CA. One downside of this model is that, since it involves a single point of trust, compromise of the root CA's private key entails entire restructuring of the PKI architecture. Also, transitioning from an existing PKI model involving multiple CAs to the hierarchical model is logistically difficult because all the end entities have to realign their trust points.
The mesh trust model is also called cross-certificate architecture, where the trust anchor of an end server is its local CA. All the CAs function independently and the trust relationship is mutual as opposed to the hierarchical model that operates with a single trust point. In this model, each CA is autonomous, performs peer-to-peer cross verification with other CAs, and the nature of trust is bidirectional. The main advantage of the mesh model is that it's easier to bring in a new community of users because there's no single point of trust and thus no need to change the existing trust points for the new users. However, this model incurs high maintenance costs and poses scalability problems.
This model is similar to the mesh model with bidirectional trust relationships but with a bridge CA acting as the hub for all the autonomous CAs involved in the architecture. In this model, the chain of trust is less complex than the mesh framework since it's traceable back to a single bridge CA. One downside of this model is that the user certificates are complex since the bridge CA relies on certificate information to establish trust relationships among the different PKI modules. This in turn poses technical challenges related to the distribution of certificates and status information in a way that's beneficial to users and applications.
The highly dynamic nature of IT networks calls for organizations to adopt trust models that are agile and scalable. As the name indicates, the hybrid trust model is a combination of two or more of the above architectures depending on the requirements of the user communities involved. The diagram below shows a hybrid model where hierarchical and single CA architectures are combined to produce a new trust framework.
Digital certificates needn't necessarily be obtained from public CAs. Users can generate self-signed certificates on their own local hosts with their own private keys instead of requesting them from a public or private CA. Organizations tend to use self-signed certificates for internal applications, tools, and processes for convenience purposes. However, using self-signed certificates—even for internal purposes—poses huge security risks. Here are a few of them:
Dangerous public browsing behavior: Self-signed certificates still produce security warnings. Employees are usually advised to ignore the warnings since they know the internal network is safe. However, this practice results in dangerous public browsing behavior, which may open up the corporate network to a plethora of security risks.
Spoofing attacks: Compromised self-signed certificates can cause attackers to spoof the identity of the victim and expand their access across the organization.
Inability to revoke: Unlike CA certificates, self-signed certificates can't be revoked. Instead, organizations can only replace or rotate the affected certificate. The inability to quickly find and revoke a compromised private key opens the door for serious security risks.
Using self-signed certificates on public facing sites can also wreak havoc on organizations' brand credibility through the display of security warnings in client browsers. Enterprises seldom use self-signed certificates on public servers.Using self-signed certificates on public facing sites can also wreak havoc on organizations' brand credibility through the display of security warnings in client browsers. Enterprises seldom use self-signed certificates on public servers.
One way to get rid of internal self-signed certificates is to set up an internal CA (such as the Microsoft CA) and configure it to create and deploy certificates for corporate entities. Validation procedures, key length, signing algorithms, and revocation processes can be customized depending on the organization's security policy.
Establishing some form of CA-level trust proves much more secure than using self-signed certificates.
CA-signed certificates, or public certificates, are digital certificates signed and issued by trusted CAs. It's highly recommended that enterprises use CA-signed certificates for public facing sites since they will be automatically verified and trusted by client operating systems. This provides a smooth browsing experience for customers and keeps away browser security warnings that can impact brand credibility. To purchase CA-signed certificates, organizations must first choose a trusted CA and the type of certificate required, create and submit a Certificate Signing Request (CSR) to the CA, and then deploy the acquired certificate to target end servers within the network.
Below is an elaborate sequence of the steps that PKI admins follow to acquire and distribute certificates from a public CA:
Selecting the right type of CA partner that meets corporate security policies is the first step towards acquiring and managing public CA certificates. The list of of things to take into consideration when evaluating CAs include:
Security reputation: Though all CA companies go through rigorous audits to obtain accreditation, not all CAs are equally secure. Even the most reputed CA firms have witnessed bad breaches in the past, so organizations need to keep an eye on SSL/TLS-related news when choosing to subscribe to a CA partner.
Pricing: Certain CA firms charge a lot (the price may go as high as $1,500 per certificate) while some firms offer the same encryption for a much lower amount. There are also open-source CAs such as Let's Encrypt and CAcert that offer X.509 certificates for free. PKI admins generally look for CA partners with the lowest certificate pricing that meet corporate requirements in terms of brand reputation and ease of use.
Customer service: Customer service is an important factor to consider when choosing CAs. Most organizations don't have a dedicated in-house PKI team and so face frequent issues during deployment and renewals. Selecting a CA that offers assistance with implementation and a simple management interface can be a huge time saver for IT teams.
Technical agility: The world of internet security is constantly changing. With new vulnerabilities being discovered everyday, it's essential that organizations choose a certificate provider that prioritizes adapting to the latest SSL/TLS security trends like certificate transparency and certificate pinning as well as newer signing algorithms like SHA-2 and ECDSA.
The Certification Authority Browser Forum, also known as the CA/B Forum, is a voluntary consortium of CAs, browser vendors, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 certificates chained to a trust anchor. Any major decisions regarding accepted certificate standards and requirements are done by passing motions in the CA/B Forum followed by a one-week voting period upon unanimous approval by all the members of the forum.
After choosing the CA, the next step is to assess and find which SSL/TLS certificate type meets your requirements. Public CA certificates can be broadly classified into three major categories. While the encryption strength remains the same for each certificate type, the difference is in the validation and vetting process involved before certificate provisioning. The three major types of CA certificates are:
Domain validated (DV SSL) certificates: Domain validation is the least stringent validation. The CA simply validates the requesting entity's legal ownership of the domain before issuing the certificate. No background checks about the organization are done. This type of certificate is best suited to small-scale businesses that require low-cost SSL encryption without having to submit company documents.
Organization validated (OV SSL) certificates: For this type of certificate, the CA verifies the requesting entity's legal ownership of the domain and also vets the organizational information to some extent, giving some enhanced visibility on the party processing your information. Web browsers have a way of differentiating between DV and OV SSL certificates by displaying the organization's name along with the certificate information, increasing the associated trust. This type of certificate is suitable for organizations collecting personally identifiable information from their customers.
Extended validation (EV SSL) certificates: In this type of validation, not only does the CA verify the legal ownership of the particular domain but conducts a rigorous vetting of the organization. Extended validation is the longest and costliest, and certificate issuance is done by adhering to the strict protocol of the EV SSL Certificate Guidelines as formally ratified by the CA/B Forum. The CA distributing an EV SSL certificate must also undergo strict audits to acquire the issuance rights. This type of certificate is best suited for large enterprises, financial institutions, and e-commerce bodies that collect and process large volumes of sensitive information.
After narrowing down your preferred CA and the certificate type, the next step is to generate a CSR and send it to the CA. The CSR is an encoded file containing the public key and some details about the certificate and the organization, and it's the accepted standard of requesting a certificate from a public CA. In short, the CA will use the data from the CSR to generate a certificate. A CSR can be viewed using a simple text editor and it usually bears the PEM or CSR file extension. Here's a sample of what a CSR looks like.
Once the CA receives a CSR, it uses the enclosed public key to decrypt the signature and gather the specified information. The CA then verifies your identity, right to the domain specified, and runs a background check on your organization (depending on the type of certificate requested). The CA then generates the X.509 certificate from your CSR, hashes and encrypts it, and signs it using the corresponding private key. The signed CA certificate is then sent back to the organization. It bears the CA's signature and its public key, and it usually has the file extension CER. The obtained certificate is then installed on target machines within the network.
Once the certificates are deployed to required servers within the network, they need to be constantly monitored for their usage. All kinds of X.509 certificates come with a set validity period, so they need to be renewed before their expiration date. Timely renewals are important as they help in staying on top of the latest encryption standards and safeguard brand credibility.
Key Manager Plus is integrated with ManageEngine’s Password Manager Pro, to provide unified privileged identity management platform.
ManageEngine’s Key Manager Plus enables us to stay on top of SSL certificates for all of our websites. With Key Manager Plus, we’re able to monitor which certificates are nearing expiration and roll out new certificates in a timely manner.Ken Odibe Senior cloud infrastructure consultant, Sapphire systems.