Certificate Authority (CA)

What is a certificate authority (CA)?

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.

SSL and TLS: How do they secure online communications?

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:

• 01

  Encryption

  When you connect to a website over HTTPS, the exchange of information is encrypted and becomes undecipherable for cybercriminals who try to eavesdrop.

• 01

  Authentication and trust

  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:

  • Public key: Details on which public key and the corresponding cryptographic algorithm are used to sign the certificate.

  • Subject: Information about the domain the certificate was issued to or, for certain types of certificates, the legitimacy of the organization operating the website.

  • Issuing CA: The signature of the trusted issuing authority that reaffirms the security of any information shared with the website.

  • Validity period: 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.

How do SSL/TLS certificates work?

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:

• The user machine's browser attempts a connection to the website's server machine secured with TLS and requests it to prove its identity.

• The web server receives the request and sends back a copy of its TLS certificate along with its public key.

• The browser receives the certificate and checks its legitimacy by comparing it with a predefined list of trusted CAs. If the browser trusts the certificate, it creates a symmetrical key called the session key, encrypts the key using the server's public key, and sends it back to the server.

• The web server decrypts the message using its private key and sends an acknowledgement—which is encrypted using the session key—back to the browser to start the session.

• The TLS handshake process is now complete. After this, the browser and the server begin the session in which all exchanged information is encrypted using the session key. This ensures that any attempted man-in-the-middle attack is rendered useless because the key to decrypt the data transfer resides only with the involved parties.

The chain of trust

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:

• Root certificate

  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.

• Intermediate certificate

  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 or end-entity certificate

  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.

Types of Trust Models in PKI

There are five broad categories of trust models within the PKI realm. They are:

• 01

  Single CA model: Direct Certification

  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.

  

• 02

  Hierarchical model: Scalable Trust Chain

  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.

  

• 03

  Mesh model: Cross Certification Architecture

  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.

  

• 04

  Bridge model: Hub-Based Trust Framework

  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.

  

• 05

  Hybrid model: Combining Trust Architectures

  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.

  

Risks of Using Self-Signed SSL/TLS Certificates

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.

Acquiring CA-Signed SSL/TLS Certificates: Step-by-Step Guide

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: