(5 votes, average: 4.20 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 10, 2020 3

What Is a Certificate Authority (CA) and What Do They Do?

in Hashing Out Cyber Security, Monthly Digest

Every time you visit a website that starts with HTTPS, you’re using a certificate authority. But what exactly is a CA and how does it make your transactions and communications more secure?

Certificate authorities (CA) are a critical part of the internet. If CAs didn’t exist, you wouldn’t be able to shop, pay taxes, or do banking online because the internet would be insecure. (Your web browser is actually using a certificate authority right now.)

But what is a certificate authority, exactly? What does a certificate authority do? And how do certificate authorities work?

Let’s hash it out.

What Is a Certificate Authority (CA)?

A certificate authority, also known as a certification authority, is a trusted organization that verifies websites (and other entities) so that you know who you’re communicating with online. Their objective is to make the internet a more secure place for organizations and users alike. This means that they play a pivotal role in digital security.

If that sounded slightly nebulous or confusing, let’s use an example to explain what a certificate authority is. Let’s say you’re visiting your bank’s website, bbt.com:

If you’re familiar with how the internet works, you know that things are not always as they seem. The website looks like bbt.com, and the domain says that it’s bbt.com… but how do you know that you’re actually connected to a server that’s run by BB&T? How do you know it’s not a hacker who built a website that looks just like bbt.com? For hacker geniuses, that’d be pretty easy to do — here’s a recent example of this kind of attack:

So how do you know you’re connected to the real website? That’s a certificate authority’s job — they verify websites/organizations so that you know who you’re communicating with online. (This way, you don’t accidentally send your credit card number to a hacker in Timbuktu.) So, if we look at the SSL/TLS certificate details for bbt.com, we can see that the website has been verified by DigiCert Inc. This means that DigiCert is the certificate authority that verified BB&T/bbt.com so you can be 100% confident that you’re connected with the official BB&T website:

Certificate Authorities Are Like Passport Authorities for the Internet

If you’ve ever gotten a passport to travel internationally, you probably remember the verification process that you went through to prove that you are who you claimed to be. (It probably included some legal papers, photo ID, and maybe fingerprints.)

Once you got your passport, you could use it to prove to anyone that you’re really you. (Even if they’d never met you before.)

Certificate authorities are like that — but for websites and online activities. Just like the passport office, a certificate authority charges a small fee to complete the verification process and issue the certificate. In this case, after they verify a website (or organization), they issue what’s known as a digital certificate. This digital file enables organizations, websites, or other entities to prove who they are — that they’re the real deal.

So how does all of this work? After all, websites don’t have actual passports, and I don’t remember scanning any passports when I visit my bank’s website…

Let’s dive into this topic in more detail.

How a Certificate Authority Works: The Technical Details

Certificate authorities are one of the integral parts that make up a larger system called public key infrastructure, or PKI for short. If you want to read more about how it works, see our article that offers a deep dive on how PKI works. But for now, let’s just give a quick overview before moving on. To keep things simple, we’ll keep talking about how PKI works with websites.

When you go to a website and see the padlock (or the security details like we showed above for bbt.com), the technology that’s enabling that is an SSL certificate (or, more accurately, a TLS certificate, but you can use either term).

SSL/TLS certificates are based on PKI, and there are a few key parts that need to be in place for the SSL certificate to work:

• A digital certificate (for example, an SSL/TLS certificate) that proves the website’s identity.
• A certificate authority that verifies the website and issues the digital certificate.
• A digital signature that proves the SSL certificate was issued by the trusted certificate authority.
• A public key that your browser uses to encrypt data sent to the website.
• A private key that the website uses to decrypt the data sent to it.

Let’s take a look at this visual. It helps to break down the process of how PKI works in website security and the role that CAs play in it:

As you can see there, the certificate authority is at the top of the process. That’s because once someone requests a certificate, everything trickles down from the CA after that.

What Does a Certificate Authority Do? Breaking Down the Functions of a CA

As we mentioned, commercial certificate authorities are integral to public key infrastructure. What they do is:

• Vet domain names, individuals and organizations to validate their identities through official records.
• Issue digital certificates that authenticate servers, individuals and organizations (establishing trust).
• Maintain certificate revocation lists that indicate when certificates become invalid prior to their expiry dates. (We’ll speak more to this later in the article.)

Let’s dive into the specific functions that they perform to explain this a bit more.

Verification

The process starts when a website approaches a certificate authority to obtain a digital certificate. The certificate authority completes a verification process, depending on the type of certificate requested:

• Domain validation — The certificate authority verifies that the requestor is the legitimate manager of the domain/website in question. That’s it. Needless to say, this means that domain validation is the bare minimum in terms of validation.
• Organization validation — The certificate authority not only verifies that the domain information is legitimate, but it goes a step further and performs basic business validation. The OV process involves a human element. Basically, the CA reviews information that the certificate requestor provides and also researches additional information (using third-party records and sources) to ensure the organization is legitimate.
• Extended validation — This is the most thorough level of business validation. In this one- to five-day validation process, the CA takes an extensive look at the requestor’s organization. They go above and beyond the requirements of the OV validation process to ensure that your organization truly is legitimate.

By requiring individuals and organizations to verify themselves, the CA is able to offer greater assurance that the requestor’s website is real.

Digital Certificates

Certificate authorities bring identity into the picture through certificate authentication. And this is what helps the website to establish trust with your browser.

Although we’ve only really talked about one type so far (SSL/TLS certificates), there are actually multiple categories of digital certificates that CAs issue — and each plays a different role within PKI. In some cases, there are multiple types of digital certificates within each category. All of these certificates are known as X.509 digital certificates because X.509 is the technical standard they all comply with.

SSL/TLS Certificates

SSL/TLS certificates (aka website security certificates) are what we’ve been talking about so far. These certs are what facilitate the secure, encrypted connections that take place between a user’s browser and your web server. (Remember that padlock icon we pointed out earlier? Yeah, these certs are what make that possible.)

These certificates are what eliminate the “not secure” warnings in the URL bar and the “your connection is not private” warning messages that browsers display for insecure websites. For example, here’s what it looks like in Chrome when no SSL/TLS certificate is installed (or if there is one but it’s improperly configured):

Types of SSL/TLS Certificates

SSL/TLS certificates are divided by their validation levels and functionalities:

• Validation levels: These are the domain, organization and extended validation types that we discussed a little bit ago.
• Functionalities:
  • Single domain certificates — As the name would implies, these types of SSL/TLS certificates secure an individual domain. (This includes both the WWW and non-WWW versions of the domain.)
  • Multi-domain certificates — These certificates allow you to secure multiple domains and subject alternative name (SAN) domains under a single certificate. (SANs are alternative host names, common names, IP addresses, etc.)
  • Wildcard certificates — The term wildcard refers to subdomains. So, a wildcard SSL/TLS certificate is one that secures an unlimited number of subdomains for one domain under a single certificate. (For example, you may see the subdomain info listed with an asterisk, like *.bbt.com or *.thesslstore.com.)
  • Multi-domain wildcard certificates — These certificates are kind of the best of both worlds. Not only do they enable you secure multiple domains under a single certificate, but they also allow you to secure as many subdomains as you want, too. Multi-domain wildcards offer the most in terms of versatility.

Code Signing Certificates

Developers and publishers use these types of certificates to digitally sign their code to ensure its integrity. This enables users to tell whether it’s been tampered with since it was signed originally. It also helps you to authenticate yourself or your organization by showing that it was you who actually signed it.

It helps you to avoid ugly warning messages like this:

Email Signing Certificates

Email signing certificates are useful for authenticating individuals and clients to web servers. These certs are also known as S/MIME certificates, personal authentication certificates, client authentication certificates, etc.

This is how an email displays when it’s signed with an email signing certificate:

If you dig a little deeper by clicking on the ribbon on the right, it offers more information that attests that the email genuinely came from my account. (More specifically, from my device’s email client.)

Document Signing Certificates

These certificates are useful for authenticating the document creator and validating the integrity of the document itself.

The way that a certificate authority gives credence to those individual certificates is by issuing root certificates that other certificates link back to. This is what we call the chain of trust (we’ll discuss that more in depth shortly).

Digital Signatures

A certificate authority applies something called a digital signature to the digital certificate. In simple terms, the digital signature:

• Proves that the certificate was issued by the trusted certificate authority.
• Validates that the certificate has not been modified or swapped out.

But can’t someone just fake a digital signature? No — because of hashing and check-sums. But that’s a whole other complex topic that’ll take us down a rabbit hole. Let’s just make this simple by saying that digital signatures can’t be copied, faked, or modified.

A Certificate Authority’s Role in the Chain of Trust

The chain of trust, a series of certificates that link back to the issuing CA, is a hierarchical trust model. This type of chain links back from the website’s server certificate to the root by way of an intermediate certificate. This means that the trust model that all public CAs use consists of:

• Root certificates,
• Intermediate certificates, and
• Server certificates.

Since the three-part trust model is what all public certificate authorities use, that’s the one that we’re going to focus on here. With this in mind, this is what the chain of trust looks like for the BB&T website:

Not sure how to read it? Think of it like an upside-down tree — the root certificates are the base/foundation, the intermediate certificates are like the tree trunk and larger branches, and the individual server certificates are the leaf certificates that have limited lifespans.

• A root certificate is a self-signed signed certificate that the CA issues and signs using its private key. A certificate authority only issues a handful of root certificates and they’re valid for extended periods of time. As you can imagine, this means that CAs closely guard and protect these certificates. Browsers and OS key stores maintain lists of these trusted root certificates.
• An intermediate certificate is issued from root certificates. A root CA can delegate its authority to issue SSL/TLS server certificates to its intermediate CAs. These entities essentially serve as the go-between for the root CA and server certificates. (So, if an attacker compromises an intermediate CA’s key, only the certificates they signed become invalid.)
• A leaf certificate is what a CA issues for your domain. This is the certificate that you upload to your server that validates your domain, subdomains, etc. (depending on the certificate). These public certificates have a limited lifespan of one year (398 days, more specifically) starting on or before Sept. 1, 2020.

But what happens when something goes wrong? For example, when a CA’s private key gets lost or the certificate otherwise becomes compromised. This is where a certificate revocation list comes into play.

A CA’s Role in Certificate Revocation

A certificate revocation list, essentially, is a blacklist of certificates that can no longer be trusted. A certificate authority adds a certificate to this list of shame to communicate that something’s wrong with a particular certificate and that it’s no longer trustworthy. This is a list that clients can reach out to CAs to check (or website servers can also check and provide info to the clients for automatically through a process called OCSP stapling).

Is a CRL the same as a CA’s certificate transparency (CT) log? No. These are two different things. Whenever a CA issues a new digital certificate, it must create a new entry on its public CT log. However, if a CA invalidates any of those certificates before their assigned expiration dates, then the CA adds those certs to their CRL. 

Why Certificate Authorities Are So Important

A certificate authority is the Issuer of Certificates, the Signer of (Public) Keys, and the Authenticator of Organizations and Individuals. (It all sounds very Game of Thrones-esque, doesn’t it? Minus the dragons and all of the requisite sex, murder, and intrigue, of course…)

Without trusted CAs to issue digital certificates, you now know that wouldn’t be able to:

• Objectively authenticate yourself or your organization,
• Encrypt data or the connections that data transmits through,
• Validate the integrity of your data.

Let’s imagine that you’re a website owner and your customers are trying to connect to your website. How do they know that they’re actually connecting to your legitimate website and not a malicious fake? A certificate authority attests that the site is owned by you and that your organization is legitimate (depending on the validation level of the cert you use). This helps to establish trust with the customers’ web browsers.

So, when the user tries to connect with your site, your server sends its public key along with a digital certificate (SSL/TLS certificate) that’s signed by the CA. Once it establishes this trust with the client through a process known as an SSL/TLS handshake (which it too complex to get into here), then a secure, encrypted connection forms between them. Encrypting the communication channel prevents any unintended parties from intercepting and stealing the data that transmits between your customers and your server. (Ever heard of a man-in-the-middle attack, or a MitM attack? That’s what this is…)

Basically, all of this is to say that without these third-party entities, your site users would never know for certain whether you are who you claim or be, or if your data has been tampered with in any way. Furthermore, you’d never be compliant with regulations and laws regarding data security and privacy. (Think HIPAA, PCI DSS, GDPR, CCPA, etc.)

All of these regulations involve the use of certificate authorities in some way. And if you’re non-compliant, leaves you facing potentially significant non-compliance fines, potential lawsuits, and losing the trust (and business) of customers. That’s going to take a heavy toll on your business financially, and the damage to your organization’s reputation may be something that you can’t come back from.

But Just How Many CAs Are There?

You may be surprised to know that there are actually a few hundred public CAs that exist globally. They’re often divided by country or region. However, it’s really just the top dozen or so that issue most of the certificates that are in use online.

Did you catch that? We said public CAs. Yes, there are actually different types of certificate authorities. You’ve got your external commercial CAs — or what are also known as publicly trusted certificate authorities. (These are what people usually refer to when talking about CAs.) But then you’ve also got your private CAs as well. And there are some important distinctions to know about public vs private CAs.

The Differences Between a Public Certificate Authority and a Private CA

While the terms seem pretty self-explanatory, we’ll go ahead and break things down a bit more regarding the players for those who are new to the game.

What Is a Trusted CA (and Why Do We Trust Them)?

A trusted certificate authority — or what’s also known as a commercial certificate authority — is a third-party entity that issues certificates for organizations that request them. They’re not controlled in any way by the person or organization that requests a certificate from them. A trusted CA issues publicly trusted digital certificates that meet at least the minimum regulatory standards (aka baseline requirements, or BRs) that are outlined by the CA/Browser Forum (CA/B Forum).

According to the CA/B Forum, which has nearly 50 CAs as members (in addition to browsers):

CA service providers will have a clear understanding of the standards that they need to adhere to when providing SSL and authentication services.  In turn, auditors will use the criteria to measure whether the CA meets industry minimum expectations.  A CA with an audit indicating that it is compliant with the Baseline Requirements will have less risk of being rejected by the leading browsers (i.e. their certificates will be more widely accepted).   Consumers will be assured of a certain level of security when they encounter SSL certificates offered by CAs that have adopted the CA/B Baseline Requirements.   The Baseline Requirements will lead to more frequent use of SSL to secure websites with stronger encryption and fewer certificate-related vulnerabilities.”

Examples of some of the biggest publicly trusted CAs (listed alphabetically) include:

• DigiCert
• Entrust Datacard
• Globalsign
• GoDaddy
• Let’s Encrypt
• Sectigo

What Is a Private CA?

A private certificate authority (also known as private PKI), on the other hand, is an internal CA that exists within a larger organization (typically an enterprise) and issues its own certificates. A private CA functions like its public counterparts in many ways, but probably the most glaring differences are that:

• A private CA’s certificates are trusted only by its internal users, clients, and IT systems.
• A private CA issues certificates that restrict access to a select group of users.
• You have to set up and host the private CA yourself (or hire a third party to do it for you).

Because these certificates are issued by an internal CA and not a trusted third-party CA, they’re best suited for use within intranets and internal networks — never any public-facing sites or endpoints. Some of the most common uses for private PKI include:

• Virtual private networks (VPNs),
• Intranet sites,
• Private email signing certificates,
• Closed user-group services, and
• File-sharing applications.

The focus of this article isn’t private CAs — but we thought it would be remiss if we didn’t at least mention them. Let’s get back to the main focus of this articles: publicly trusted certificate authorities.

Who Decides Which Certificate Authorities Are Publicly Trusted?

That’s a good question — and there’s not one answer to it. For example:

• Microsoft decides which CAs are trusted by Windows machines,
• Mozilla decides which CAs are trusted in Firefox and Linux machines,
• Apple decides which CAs are trusted on their Safari browser, device operating systems, etc.

Final Thoughts on Certificate Authorities and Why They Matter

The internet is inherently insecure. It puts all of the world’s information at your fingertips and offers an unparalleled level of convenience. But as you can imagine, all of those benefits don’t come without a hefty price tag.

All you have to do is look at news headlines to see that cyber attacks, data breaches, identity theft, and other threats and dangers lurk everywhere. If you want to be able to surf the web or use its capabilities to benefit your ecommerce business, that’s why you need to have a trusted third party on your side who can bring identity and trust to the table.

At their core, the job of CAs is to make the internet a more secure place for organizations and users. As such, they’re responsible for:

• Validating individuals and organizations,
• Issuing digital certificates that authenticate and facilitate encryption, and
• Maintaining the certificate revocation lists that web browsers and servers rely on to know which certificates are no longer legitimate.

Cybercrime events and the costs associated with them continue to increase with no end in sight. This is why it’s crucial for every website — ecommerce sites in particular — to have an SSL/TLS certificate from a trusted certificate authority. We hope this article provides you with a greater understanding of what a certificate authority is and what it does.

• #Certificate Authorities