(2 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

July 5, 2023 Comments closed

What Is a CA Certificate? An Overview of These Key PKI Elements

in Everything Encryption, Hashing Out Cyber Security

CA certificates are the small digital files that make digital trust, digital identity, and security possible—whether across the internet or within your company network.

Certificate authority certificates, or CA certificates, are found virtually everywhere within your organization’s IT environment. In fact, you’ve probably got dozens of them on your computer/device… and you even used several of them to be able to read this article.

Whether you’re operating an eCommerce website or digitally signing your latest software patches, these digital files and their cryptographic keys are what help to protect your customers and data against attackers and compromise.

But what is a CA certificate, and how does your organization use different CA certs within its environment?

Let’s hash it out.

What Is a CA Certificate? A Brief CA Cert Definition and Explanation

A CA certificate is a digital certificate that a trusted entity (certificate authority) issues to help create a digital trust chain. These certificates come in a few varieties (that we’ll talk about later), but their purpose is to help organizations:

• Ensure data confidentiality using public key cryptography. Using trusted CA certificates enables you to transmit information securely.
• Enable digital identity validation for authentication and non-repudiation. This proves you are who you say you are, and that you (and no one else) are responsible for creating or sending something),
• Achieve data integrity verification through cryptographic hashing. Hashing helps you prove that your data hasn’t been compromised since it was signed.

And CA certificates, much like the CAs that issue them, are integral components of public key infrastructure (PKI). This is the backbone that internet security stands upon. Without PKI and CA certificates, data transmitted online is inherently insecure and vulnerable to compromise.

CA certificates are issued by publicly trusted CAs or internal, private CAs. Every CA certificate has a public-private key pair. Many organizations have a mix of both types of certificates in use on their networks, websites, and email clients, which we’ll discuss more in a little bit. But first, let’s explore the trust chain that these certificates create.

CA Certificates Help Form a Chain of Trust for Digital Security

The certificate chain — also called a trust chain, chain of trust, or certificate path — is the hierarchy that proves where a certificate came from and how it links back to a trusted CA. Think of it like genealogy: you came from your parents, your parents came from their parents (i.e., your grandparents), and your grandparents came from their parents (your great-grandparents). You can keep tracing back like this to explore your family’s lineage.

Digital certificates are much the same. By looking at a certificate chain of trust, you can trace back where the certificate came from in terms of what certificate authorities helped create and digitally sign it:

Certificate Paths Provide Insulation and Structure to Protect Your PKI

When most people think of a digital certificate, they think of an end-user certificate. A popular example of this is an SSL/TLS certificate that you likely have installed on your website. But this is only one type of digital certificate, and that certificate had to come from somewhere, right? This is where intermediate CA and root CA certificates come into play.

A common analogy for the chain of trust is to consider a tree:

• The tree’s roots represent a CA’s root certificates.
• Its trunk and limbs represent an intermediate certificate authority (ICA).
• Its leaves represent end-user and device certificates (hence why they’re sometimes called “leaf” certificates).

Root Certificates

A root CA certificate is also known as a trust anchor. A certificate authority uses the root CA certificate’s private key to digitally sign an intermediate CA certificate. Each root CA certificate is generated using the most stringent processes (using air-gapped servers, a secure room or facility with physical and data security mechanisms in place, etc.) and must adhere to certain compliance standards. As such, each root CA certificate offers assurance that whatever it signs is trustworthy.

Although they’re technically free to generate, root CA certificates require loads of time and resources to achieve compliance and be included in operating systems, browsers, etc. These certificates also have longer lifespans than other digital certificates (as illustrated in the far-out expiration dates listed in the screenshot below).

Root CA certificates are also significantly more difficult to replace when things go sideways, since everything that stems from a compromised root would also be considered compromised and would need to be revoked and replaced. As such, certificate authorities only have a handful of root CA certificates and keep them heavily guarded and stored in highly secure, offline environments.

Intermediate Certificates

So, we know that the root CA signs the intermediate certificate. Likewise, the ICA certificate digitally signs leaf certificates using its private key. Doing this creates a buffer between the end-user certificates and the root CA certificates that they chain back to. Generally, there are three levels in a certificate path. However, some trust chains use multiple ICA to create additional buffering between root and end certificates. (In the latter cases, one ICA certificate’s private key signs another ICA’s certificate, which can then be used to sign the leaf certificate.)

Why not just issue the end-user certificates directly from the root? Because doing so is a bad idea. Sure, public SSL certificates used to be issued directly from root CAs for years. But as a species, we’ve done a lot of things we shouldn’t do because we didn’t know any better — like using bloodletting to treat fevers or smallpox, or adding lead to makeup or foods. Likewise, issuing certificates directly from the root CA is a bad idea because it would require the root CA to be available/online for issuance.  

It’s a lot harder to replace a compromised root CA than a compromised ICA. By isolating your root CA (i.e., keeping it offline) and using intermediate CAs to issue leaf certificates, if something happens to one of the ICAs (i.e., its signing key becomes compromised), only the certificates issued by that specific ICA will be affected.

End User Certificates

Finally, we have the end-user certificates. These certificates, which have shorter lifespans than ICA and root certificates, are digitally signed by one or more ICAs. They’re used to:

• Secure website domains (SSL/TLS certificates, or what are known as website security certificates)
• Enable passwordless authentication for identity and access management (authentication certificates)
• Digitally sign and encrypt Microsoft Office documents and PDFs (document signing certificates)
• Encrypt and digitally sign emails (email signing certificates)
• Digitally sign code and executables (code signing certificates)
• Authenticate your IoT devices and help secure their data (device certificates)

For a more in-depth look at the chain of trust, be sure to check out our other article on the topic:

• Explaining the Chain of Trust
• The Difference Between Root Certificates and Intermediate Certificates

CA Certificates Can Be Used for Public (External) or Private (Internal) Uses

Public and private CAs alike have certificate trust chains, but only public CA certificates are automatically trusted by browsers and third-party software and services. So, how do you know what type of CA you should use? The decision about whether to use a public or private CA certificate to secure your digital assets depends on where and how you plan to use it.

When to Use Public CA Certificates

Public CA certificates are digital files that publicly trusted certificate authorities (such as DigiCert and Sectigo) issue to help create digital trust in public environments. This includes securing:

• Web applications and domains,
• Production environments, and
• Other public-facing digital assets.

So, why must you use public CA-issued certificates instead of private certificates in these environments? It’s necessary because the internet is inherently insecure; it’s an open network that transmits all data in the open (i.e., in plaintext, readable formats). This means that anyone who knows how can read your sensitive data — everything from your login credentials to your customers’ personal and financial data.

If you try to use a private CA certificate in public-facing applications, then they won’t be trusted and will display error warnings.

When to Use Private CA Certificates

A common example of a private CA used by many companies is a custom CA they create and manage using Microsoft CA (a feature in Windows Server). Organizations use private CAs certificates for internal environments and applications when public trust isn’t needed. They should never be used for public-facing servers, systems, or services. Examples of private CA uses include:

• Securing intranet connections and servers,
• Digitally signing software during the development process,
• Securing development and testing servers, and
• Protecting other local devices, services, and other resources.

Does this mean you can’t use publicly trusted certificates for these use cases? Nope. You can still choose to do that (depending on the project requirements). But relying on a private CA for these internal use cases is more cost-effective when done at scale. It also gives you a lot more flexibility to customize your CA to exactly fit your project requirements.

Trusted CA-Signed Certificates vs Self-Signed Certificates

You’ve probably heard of self-signed certificates — if you haven’t, here’s your quick intro. Self-signed certificates are free and can be issued instantly because they don’t require issuance by a CA. However, unlike their CA-signed counterparts, they have many drawbacks:

• No revocation. Self-signed certificates are irrevocable by a CA. So, if something goes wrong, you’re in a world of trouble);
• A lack of validation. Self-signed certificates are unvetted, therefore untrustworthy and create a false sense of security; and
• Inherent insecurity. Relying on self-signed certificates leaves your systems and data vulnerable to compromise.

These certificates differ from those issued by public and private CAs, both in terms of their trustworthiness and how they’re created. Anyone can generate a self-signed certificate. But that doesn’t mean that the certificate will do you any good in terms of security; they’re inherently untrustworthy because they aren’t issued by a trusted entity.

This is why it’s better to use private CA certificates for internal uses and publicly trusted CA certificates for external ones.

Let’s Wrap This Up With a Few Final Thoughts

CA certificates, particularly those issued by publicly trusted CAs, provide your organization and its digital assets with the highest levels of security, digital identity authentication, and data integrity protection. They’re some of the critical components that make PKI (and internet security as a whole) possible. And when you compare it to self-signed certificates, it’s easy to see why using a CA certificate is incomparable.

CA certificates are possible through both public and private CAs. Although they serve different purposes and use cases, each has its advantages for organizations. Of course, you should use publicly trusted digital certificates to protect your external-facing assets. But this doesn’t mean that you also can’t take advantage of private CA certificates for internal applications.

Don’t want the hassle of setting up your private CA? No worries. You can opt for managed PKI (mPKI or PKI-as-a-service) if that suits your operations, knowledge, and IT team’s skillsets better. Using an mPKI helps to ensure you remain compliant with industry privacy and data security regulations. 

• #CA Certificate
• #PKI Certificate