What is a certificate authority, and how does it work?

Certificate authorities (CAs) are entities responsible for checking the identities of websites, individuals, and organizations and issuing digital certificates. They play a crucial role in online security, but most people, particularly those who have never set up their own websites, have little knowledge of these authorities or what they do.

This guide is here to shed some light on the topic, exploring what a certificate authority is, how it works, and why it matters.

What is a certificate authority?

A certificate authority is a trusted organization that works to verify the identities of websites and their owners and then issues them with digital certificates (almost like online ID cards) to confirm they are who they say they are.

These certificates prove that a public key belongs to the entity it claims to represent, helping establish secure, encrypted connections and preventing impersonation or man-in-the-middle attacks.

Basically, a CA acts as a digital notary, validating ownership and ensuring that users can trust the authenticity of the parties they’re communicating with online. Web browsers rely on CAs to help them differentiate between secure, genuine sites and fraudulent ones.

The role of certificate authorities in digital security

CAs are vital for digital security, as they help to tell legitimate sites apart from fake ones. If we didn’t have CAs, it would be much harder to figure out whether a site is real and safe to access or fraudulent and malicious. That would make numerous online activities, like online banking, commerce, and communication, much riskier for all involved.

History and evolution of CAs

CAs first emerged in the mid-1990s, building on the development of public key infrastructure (PKI). PKI is a system for managing digital certificates and public encryption keys, facilitating secure data exchange and user authentication.

The very first commercial CA was VeriSign, which was set up in 1995. Since then, as the years have passed, CA technology has improved to incorporate stricter security standards, and numerous new CAs have been established, like GoDaddy, GlobalSign, and DigiCert.

Industry-wide guidelines have also been published, like the CA/Browser Forum Baseline Requirements, which essentially serve as rules or guidelines that trusted CAs need to follow for secure operations.

How certificate authorities validate and issue digital certificates

The main role of CAs is to validate websites and their owners and then issue digital certificates so that browsers can ensure they’re taking users to safe, legitimate sites. Here’s a closer look at how that process actually works.

The certificate lifecycle: From request to expiration

Every digital certificate follows a stage-based lifecycle, from the initial request through to verification, issuance, and, eventually, expiration. Here’s a brief look at the full process, stage by stage:

1. Request: First, a website owner or organization has to make a request to receive a TLS/SSL certificate. This involves the submission of a Certificate Signing Request (CSR) with their public key and identifying details (such as the domain name) to their certificate authority of choice.
2. Verification: The CA then checks the CSR and performs checks based on the certificate type. For example, a Domain Validation (DV) certificate may only require proof of domain ownership (via email, DNS record, or file upload), while Organization Validation (OV) and Extended Validation (EV) certificates require deeper identity and business checks.
3. Issuance: Provided the site passes the verification process, the CA issues and signs the certificate, using its own private key. The certificate is then issued to the site, with details about its domain name, owner, and the validity of the certificate itself.
4. Installation: The site owner can then go ahead and install their certificate on their server. From that point on, while the certificate is valid, whenever users connect to the site, their browsers will be able to see and review the certificate. They’ll check that it’s valid and signed by a trusted CA and that the domain details match before forming a connection.
5. Expiration/Renewal: The certificate will expire after a set period (currently a maximum of 398 days). At that point, or beforehand, the owner will need to renew it. If not, browsers will be able to see that the certificate is expired and issue a warning to users.
6. Revocation: This final stage doesn’t apply to all certificates, but those that are found to be misused, fraudulently issued, or stolen may be revoked. Revocation status is checked by browsers using mechanisms like CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol).

Types of digital certificates (DV, OV, EV)

There are three main varieties of TLS/SSL certificates:

• Domain Validated (DV): These are the most basic of the three forms of digital certificates, as they merely confirm that the applicant owns or controls the domain in question. They don’t involve any actual background check or verification of the applicant’s identity. They’re best used on small, personal, or internal sites.
• Organization Validated (OV): These involve the CA verifying not just domain ownership but the legitimacy of the owner itself. The CA looks up the name, address, and contact details for the owning organization to verify they are who they say they are. OV certificates are used for corporate sites and small- to mid-sized business sites.
• Extended Validation (EV): EV certificates offer the highest level of verification and involve an extensive background check on the site owner. The owner’s name is displayed in the certificate details. EV certificates are used by the likes of government agencies and financial institutions.

Root vs. intermediate certificate authorities

We can divide certificate authorities into two core groups: root and intermediate.

• Root: Think of root CAs as the Supreme Court of digital trust. They sit at the very top of the public key infrastructure (PKI), with the highest authority. Root certificates are self-signed and are pre-installed in the trusted root stores of operating systems and browsers. Because of the huge risk if a root key were ever compromised, root private keys are kept under the strictest security controls (often offline) and are rarely used directly to issue website certificates. Instead, their main role is to sign and authorize intermediates.
• Intermediate CAs: These act like the lower courts, handling the day-to-day work of issuing and signing certificates for websites and organizations. Root CAs delegate trust to them, creating one or more layers of certificate chains. Most SSL/TLS certificates in use today are either issued by intermediate CAs (the standard for public websites) or are self-signed (rare on the public web but common for testing or internal purposes).

When a browser encounters a website’s certificate, it follows this chain of trust: from the website’s end-entity certificate, through the intermediate(s), all the way back to a trusted root. If the chain is unbroken and every certificate is valid, the site is considered secure and trustworthy.

Certificate revocation: CRL vs. OCSP

As mentioned earlier, browsers have to check if a website’s certificate is still valid and hasn’t been revoked or expired before establishing a connection with the site in question. They have two ways of doing this:

• Certificate Revocation List (CRL): This is a list of revoked certificates, published and shared by a certificate authority. A browser can download the list and scan it to see if a specific site is on it or not.
• Online Certificate Status Protocol (OCSP): This involves the browser directly communicating with the CA server to see if a specific certificate is still valid.

Both methods have their pros and cons. CRL works offline once the initial list has been downloaded, but the lists themselves may not always be completely up-to-date. OCSP often provides a more reliable, real-time response but can be slow to load and requires the OCSP server to be up and operational at the time, which isn’t always the case.

Why certificate authorities matter for HTTPS and encryption

Together with other cybersecurity tools, like VPNs and data encryption algorithms, CAs are integral in establishing trust on the internet and allowing users to confidently and safely access the sites they want, with reduced risk of running into fake or fraudulent sites along the way.

How CAs establish trust on the internet

When you visit an HTTPS website, you need the TLS/SSL certificate for the website, so your device starts a TLS handshake with a "TLS CLIENT HELLO" packet. This packet requests the public key for the website to encrypt your request.

Without a CA, an intermediate device could intercept this request and respond with its own certificate, which you would then use to encrypt your request. This breaks the entire encryption tunnel and means someone else can read your requests and server responses without you knowing.

With a CA, this is impossible because, when you receive the TLS certificate, you can request the public key for the CA and check if the signature is valid. An attacker can still intercept the public key request and replace it with their own key, but you don't request the root CA's public key; it’s already installed in your OS. In other words, there’s nothing an attacker can do to sign their bogus CA keys with the root CA private key.

In essence, it’s thanks to CAs that browsers can tell if a site and its owners are legitimate. CAs make it harder for malicious actors to fool users with fake and fraudulent sites and help the average user stay safer while browsing the net.

What is an HTTPS certificate?

An HTTPS certificate, more formally called an SSL or TLS certificate, is a file that enables secure, encrypted communication between a user and a website. If a website address begins with HTTPS, that’s a sign that it has a legitimate TLS certificate issued by a certificate authority.

However, it’s important to note that HTTPS indicates secure transmission, not necessarily that the site itself is safe or legitimate. Attackers can also obtain valid certificates for malicious domains.

How encryption works in browser communication

When you visit an HTTPS website that has been issued a security certificate by a CA, the data passing between your device and the website server is encrypted using the Transport Layer Security (TLS) encryption protocol.

TLS combines asymmetric encryption (public/private keys) and symmetric encryption (session keys) to secure communications. The website’s certificate contains a public key, while the site owner keeps the corresponding private key secret.

During the TLS handshake, your browser verifies the site’s certificate against trusted CAs. It then uses the public key to securely establish a random session key. From that point on, all communication is encrypted with this session key, making it unreadable to anyone attempting to intercept the traffic.

How browsers and operating systems trust certificate authorities

There are many certificate authorities out there, and they’re not all equal in terms of the way they work and the level of trust they provide. Browsers and operating systems have various means at their disposal to tell the most trusted CAs from the rest.

Certificate trust stores and root programs

All major operating systems (Windows, macOS, Linux, Android, and iOS) and major browsers (Chrome, Firefox, Edge, and Safari) have built-in root stores or participate in root programs. These stores contain lists of CAs that have successfully passed audits and proven themselves trustworthy over time. Only CAs that comply with industry standards such as the CA/Browser Forum Baseline Requirements are included.

When a browser first connects to a site, it scans the site’s certificate and then builds a chain of trust, looking at which intermediate CA(s) issued the certificate and tracking the chain back to the original root CA responsible. If the root CA isn’t in the browser’s root store, the browser will usually issue a warning to the user.

What causes a certificate authority to be distrusted?

A CA may become distrusted if it’s found to compromise the core trust model that underpins HTTPS and CA functionality. For example, if a CA issues certificates improperly, without thoroughly validating domain ownership or site owner identity, it may be seen as less trustworthy.

Equally, CAs that suffer hacks or data breaches, fail to comply with industry standards, or mismanage certificates may also fall off the “trusted” lists.

How to choose a trusted certificate authority

If you’re a site owner seeking to get certified, you can take your pick from a vast array of CAs. For the best results, it’s recommended to opt for a trusted, proven, and recognized CA. Here’s a closer look at how to do that.

Factors to consider: Security, compatibility, and support

To find the right CA for you, consider:

• Security: Look for CAs that have a strong reputation and a long track record of providing secure and reliable validation and certification, rather than one that may have suffered breaches, leaks, or other issues in the past.
• Compatibility: To ensure that the largest possible audience can access your site, seek out a well-known CA that features in the root lists of most or all major browsers and platforms.
• Support: You might need some assistance installing or renewing your certificate in the future, so it helps if the CA you work with has responsive and helpful support staff to assist you.

Well-known certificate authorities and their reputation

Some of the top CAs include:

• DigiCert: One of the most trusted CAs, with strong security practices and compatibility.
• GlobalSign: Founded in 1996, this is one of the longest-running CAs.
• GoDaddy: This famous web hosting provider is also a trusted CA.
• Sectigo: One of the larger CAs; has had some misissuance issues in the past but is generally trusted.
• Let’s Encrypt: A nonprofit CA launched in 2016 to make HTTPS more accessible.

Tips for verifying a CA's authenticity

• Do your research: Look up CAs to find out about their origins, history, and any issues or incidents they’ve experienced.
• Check root lists: Check to see if your chosen CA is included on root lists for popular browsers and devices.
• Seek expert assistance: If you have any doubt about which CA is right for you, consider speaking with web experts to provide answers and guidance.

The future of certificate authorities and digital trust

The CA landscape has changed a lot over the years and will continue to evolve in the years to come, in alignment with emerging trends, technologies, and standards of digital trust.

Emerging threats and quantum-resistant PKI

CAs and public key infrastructure are at risk from the upcoming age of quantum computing, as quantum computers could, theoretically, break the cryptographic algorithms used in digital certificates. Steps are underway to mitigate these threats, like transitioning to post-quantum algorithms and the development of quantum-resistant PKI technologies.

The role of CAs in a zero-trust architecture

Zero-trust architecture is a security framework built on the foundation of never assuming that any device or user is trustworthy and always verifying and authorizing every single access request. CAs align nicely with zero-trust approaches, since they help to support the continuous authentication of users, devices, and digital platforms.

What happens when a certificate authority is compromised?

If a CA becomes compromised through a stolen key or system intrusion, numerous consequences can ensue, possibly putting innumerable users, devices, and digital services at risk. It all depends on the exact nature of the incident.

A compromised CA could, for example, be used by attackers to issue seemingly valid security certificates to any domain they want, tricking users into visiting false and malicious platforms, which can then be used to spread malware or for phishing attacks.

For example, in the DigiNotar breach of 2011, fraudulent certificates were issued for major domains, leading to DigiNotar’s swift removal from browser trust stores and its collapse.

The good news is that mitigation has improved significantly in recent years thanks to strategies like public logging of issued certificates (Certificate Transparency), hardware-based key protection, strict audits, and revocation of compromised certificates.