What is a CA? Certificate Authority Definition, Types, Examples

Imagine walking into a vast library, seeking a single book among millions. Without a librarian or a catalog system, you’d be lost. In many ways, the internet is that library, and a central certificate authority (CA) is the librarian guiding us to the websites and services we can trust.

In this article, we’ll discuss what CAs are, the different types of CAs an organization may use, what CAs are used for, how the certificate chain of trust works, and best practices for securing networks and resources.

What Is a Certificate Authority?

A certificate authority is a trusted organization that issues, signs and revokes digital certificates. CAs are used to secure HTTPS connections, Wi-Fi, virtual private networks (VPNs), email, software and other systems that need to verify digital identities.

A digital certificate binds an identity to a public key. The CA verifies information about the entity requesting the certificate and then uses its private key to digitally sign the certificate. Systems can use that signature to verify that the certificate came from a trusted CA and has not been altered.

CAs play a central role in establishing digital trust. When a device or application encounters a certificate, it can check whether the certificate was issued by a CA it trusts and whether the certificate is valid for the intended use.

If a site has a certificate issued by a recognized CA, it’s like having a seal of approval, assuring users that their data is in safe hands.

A certificate authority acts as a trusted third party that verifies identities and establishes a basis for trusting the public keys associated with those identities.

CAs are the core component of a public key infrastructure (PKI), which provides the policies, processes and technologies used to issue, manage and revoke digital certificates and keys.

CAs support a wide range of use cases, including web security, Wi-Fi and VPN authentication, user and device identity, code signing, email security and document signing. These certificate types and use cases are covered in more detail below.

Watch the video below for a quick breakdown on how Wi-Fi certificate authentication works:

How Do Certificate Authorities Work?

Certificate authorities establish trust in digital certificates by verifying identities, issuing certificates and managing them throughout their lifecycles. This process relies on public key cryptography to connect a verified identity to a public key and give systems a way to verify that identity.

You can think about certificates as a stronger alternative to passwords. It’s like a passport that can be locked onto a device that says you should get into the system and you should be authorized this level of access.

Micah Spady, Director of Product Marketing at SecureW2

Three parts of the process are especially important:

• Public key cryptography: CAs use public and private key pairs to create the cryptographic relationship that allows certificates to establish trust.
• Certificate issuance: When an entity requests a certificate, the CA validates the request, signs the certificate and binds the verified identity to its public key.
• Certificate lifecycle management: After issuance, certificates must be deployed, monitored, renewed and revoked when they should no longer be trusted.

How Public Key Cryptography Supports CA Trust

CAs rely on public key cryptography, which uses a mathematically linked pair of keys: a public key that anyone can share and a private key that the owner must keep secret.

The certificate contains the entity’s public key along with identity information, and the CA signs the certificate with its own private key. This signature allows systems to verify that the certificate came from a trusted CA and has not been altered.

The entity uses its private key to prove that it controls the corresponding public key and to perform operations such as creating digital signatures or participating in secure cryptographic exchanges.

In TLS and other protocols, public key cryptography helps establish secure sessions, typically by protecting symmetric keys.

How CAs Manage the Certificate Lifecycle

Issuing a certificate is only one part of the CA process. Certificates must be managed throughout their lifecycle to keep them valid and trusted.

A typical certificate lifecycle includes these stages:

1. Certificate request and validation

The organization or device generates a public-private key pair and creates a certificate signing request (CSR). The request is submitted to the CA, which validates the identity and other information required for the certificate type.

For publicly trusted TLS certificates, the CA follows established validation requirements to verify domain control and, when applicable, organization information. The validation requirements vary by certificate type.

2. Certificate issuance and deployment

After successful validation, the CA signs and issues the certificate. It is then installed on the appropriate server, device, or service and configured for its intended use, such as HTTPS, Wi-Fi authentication or VPN access.

3. Ongoing certificate monitoring and validation

Once deployed, systems routinely validate certificates before establishing connections. This can include checking the validity period, intended use and chain of trust.

Depending on the environment, systems may also check whether a certificate has been revoked through mechanisms such as a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP).

Learn more about CRL vs. OCSP by watching the video below:

4. Certificate renewal

Certificates expire after a defined period. As a certificate approaches expiration, the organization requests and deploys a replacement to prevent authentication failures or service disruptions.

Automated enrollment and renewal are particularly important in environments with large numbers of users, devices or certificates.

5. Certificate revocation

A CA can revoke a certificate before it expires when it should no longer be trusted. Reasons may include:

• The certificate’s private key is suspected to be compromised or exposed.
• Information in the certificate is no longer accurate.
• An error occurred during application or issuance.
• A security incident or policy violation requires the certificate to be invalidated.

The CA then updates revocation information so systems can determine that they should no longer trust the certificate.

Types of Digital Certificates Issued by Certificate Authorities

Digital certificates are electronic credentials that bind an entity’s identity to a public key and are digitally signed by a trusted certificate authority. They allow systems to verify that a public key belongs to the entity identified in the certificate.

CAs issue different types of digital certificates depending on what needs to be authenticated and secured, from websites and servers to users, devices, software and documents.

TLS/SSL Certificates and Validation Levels

Transport Layer Security (TLS) certificates secure web traffic by enabling HTTPS and authenticating servers to clients. Although SSL is the older protocol that TLS replaced, the term “SSL certificate” is still commonly used to describe TLS certificates.

Publicly trusted TLS certificates generally fall into different validation categories based on what the CA verifies. These are outlined in the table below.

Validation Level	What the CA Verifies	Trust/Assurance	Typical Use
Domain Validation (DV)	Domain control only (automated DNS/file check)	Basic — encrypts traffic, no org identity confirmed	Personal sites, blogs, internal tools
Organization Validation (OV)	Domain control + organization name, address, and contact details	Medium — confirms a real organization owns the domain	Business websites, portals, customer-facing apps
Extended Validation (EV)	Domain control + legal existence, jurisdiction, and authorization checks	High — most rigorous identity verification available	E-commerce, banking, regulated industries

The CA/Browser Forum establishes requirements for publicly trusted TLS certificates, including identity validation, certificate issuance and lifecycle management. Its current requirements also define increasingly shorter maximum validity periods for public TLS certificates.

Code Signing and Application Certificates

Code signing certificates allow software publishers to digitally sign executables, installers, scripts and other software.

The signature allows systems and users to verify the publisher’s identity and detect whether the signed code has been modified since it was signed. This makes code signing an important part of software distribution and supply chain security.

User and Device Authentication Certificates

User and device authentication certificates are issued to individual users or specific endpoints rather than public web servers.

They can replace passwords for network authentication, including Wi-Fi and VPN connections, and can support identity-based access across large enterprise environments.

For example, organizations can use certificates with 802.1X and EAP-TLS to authenticate users and devices before granting access to a network.

Organizations using a managed PKI platform can automate the issuance and renewal of user and device certificates at scale, eliminating the manual overhead of traditional certificate management.

The video below breaks down the core components of PKI & certificate management, including issuing, managing and revoking certificates:

Email and Document Signing Certificates

Email and document signing certificates use digital signatures to help recipients verify the identity of the sender or signer and detect whether signed content has been modified.

Depending on the certificate and application, digital signatures can also support encryption and secure exchange of information.

Types of Certificate Authorities

Not all CAs serve the same purpose. Certificate authorities are responsible for issuing various types of digital certificates, including SSL certificates, which are critical for secure internet browsing.

There are several ways to categorize certificate authorities based on their role, trust model and deployment environment. Root and intermediate CAs describe a CA’s position in a certificate hierarchy, while public and private CAs describe who can trust the certificates they issue. Other CA models, such as specialized and cross-certified CAs, serve more specific environments.

Root Certificate Authorities

Root CAs are at the top of the digital certificate hierarchy. They are trusted entities that issue digital certificates to Intermediate CAs or, less commonly, directly to end entities.

Root CAs have self-signed certificates that are embedded in web browsers and operating systems, establishing a chain of trust. When a web browser or device recognizes a root CA’s certificate, it trusts all certificates issued by that CA.

Intermediate Certificate Authorities

Intermediate CAs serve as a bridge between the root CA and the end entities (such as websites). The root CA issues them certificates, which they use to sign end-entity certificates.

This multi-layered approach enhances security by keeping root CAs protected from public exposure and allowing compromised intermediate certificates to be revoked without affecting the root CA.

Public Certificate Authorities

Public CAs issue certificates that are intended to be trusted outside an organization’s own environment. Their root certificates are included in the trust stores maintained by major operating systems, browsers and other applications. This allows devices to automatically trust certificates that chain back to an approved public CA.

Examples include Let’s Encrypt, DigiCert, and Sectigo. They offer a range of certificates catering to different levels of authentication, including DV, OV and EV.

Private Certificate Authorities

Private CAs are internal to an organization and not trusted by devices and browsers outside the organization’s domain. Organizations use private CAs to issue certificates for internal servers, user authentication, email encryption and secure communication within an organization.

Because they operate within a controlled environment, private CAs allow organizations to manage their security policies and certificate lifecycle closely.

Is a private CA Wi-Fi more secure than a public CA Wi-Fi? Yes and no. It’s not inherently more secure because of any infrastructure or software differences. It is more secure because there are fewer links in the chain and less potential failure points.

SecureW2 Guide to Private CAs

This table summarizes the differences between public and private CAs:

Dimension	Public CA	Private CA
Trusted by Default	Yes — root certs pre-installed in browsers and operating system trust stores	No — must be distributed to devices in scope
Certificate Scope	Public-facing websites, services, and externally accessible endpoints	Internal servers, users, devices, and private network resources
Cost Model	Per-certificate or subscription fees to a commercial CA	Upfront infrastructure or SaaS subscription; lower per-cert cost at scale
Lifecycle Control	CA sets policies; organization requests and renews	Organization controls issuance, renewal, and revocation policies
Typical Use	HTTPS for public websites, externally trusted code signing	Wi-Fi authentication, VPN, internal app security, device identity

There are many private certificate authority companies and services available today that make it simple to deploy your own CA.

SecureW2 is a private certificate authority service that allows organizations to create as many CAs and manage the entire certificate lifecycle from a single pane of glass.

In fact, with SecureW2 support, a global retail brand deployed an internal CA across 4,000+ devices, replacing legacy infrastructure with a private CA built for scale.

Self-Signed Certificate Authorities

While not formally CAs, entities can issue self-signed certificates, where the certificate’s issuer is also the certificate’s subject.

Primarily used for testing, development, or internal applications, self-signed certificates are not verified by an external CA and, therefore, not inherently trusted by web browsers or operating systems.

Users often have to manually accept or install the certificates to bypass security warnings.

Warning: Self-signed certificates provide a basic level of security for internal communications but are not suitable for public-facing applications where trust and authentication are critical.

Specialized Certificate Authorities

Some CAs serve specific niches or industries. For example, government or military organizations may have their dedicated CAs for internal and secure communications.

Healthcare industries might also rely on specialized CAs that comply with industry-specific security standards and regulations. These CAs provide tailored services and certificates that meet the unique requirements and trust models of these sectors.

Cross-Certified Certificate Authorities

Cross-certification is a process in which two or more CAs exchange certificates, extending trust among themselves. This method allows entities that hold certificates from one CA to be trusted by another CA without needing direct certification from the latter.

Cross-certification is useful in environments where interoperability between different security domains or trust networks is necessary.

What Is a Certificate Chain of Trust?

A certificate chain, often called a trust chain, is a sequence of certificates that allows a recipient to verify the trustworthiness of a certificate presented by a server, device, user or other entity.

The chain typically consists of three levels:

• Root CA: The root CA sits at the top of the hierarchy. Its certificate is self-signed and serves as a trust anchor. Public root certificates are distributed through trusted operating system, browser and application trust stores.
• Intermediate CA: An intermediate CA receives its certificate from a trusted root or another CA above it in the hierarchy. It issues certificates to end entities while allowing the root CA’s private key to remain protected.
• End-entity certificate: The end-entity, or leaf, certificate is the certificate presented by a website, device, user or service. It contains the entity’s public key and identity information and is signed by an issuing CA.

How Does a Certificate Chain Work?

When a system encounters a certificate, it works backward through the chain to determine whether the certificate can be trusted:

1. The end-entity certificate is presented. For example, a website presents its TLS certificate when a browser connects over HTTPS.
2. The issuing CA is identified. The system checks which CA signed the certificate and locates the corresponding issuer certificate.
3. The chain is validated. The system verifies the signatures and validity of each certificate while moving toward the root.
4. The root CA is checked against the trust store. If the chain ends at a trusted root and the certificates meet the applicable validation requirements, the certificate can be trusted.
5. The certificate’s intended use and status are checked. The system can also verify factors such as validity dates, permitted uses and, where supported, revocation status.

The layered structure helps protect the root CA’s private key. Root CAs do not generally need to perform routine certificate issuance directly. Instead, intermediate CAs handle day-to-day issuance, limiting the exposure of the root key and allowing individual intermediate certificates to be replaced or revoked without replacing the entire trust anchor.

If the chain cannot be validated — for example, because a certificate is expired, an intermediate certificate is missing or a trusted root cannot be found — the browser or application may display a certificate warning.

How CAs Are Preparing for Post-Quantum Cryptography Migration

Certificate authorities are an important part of the transition to post-quantum cryptography because certificates and their signatures rely on public-key cryptographic algorithms.

In August 2024, NIST finalized its first set of post-quantum cryptography standards:

• FIPS 203 / ML-KEM for key establishment
• FIPS 204 / ML-DSA for digital signatures
• FIPS 205 / SLH-DSA as a hash-based digital signature alternative

These standards form the foundation of the industry’s transition away from traditional algorithms such as RSA and elliptic-curve cryptography, which could eventually become vulnerable to large-scale quantum computers.

For certificate authorities, this migration presents a unique challenge.

A typical X.509 certificate hierarchy contains a root certificate authority, one or more intermediate certificate authorities, and the end-entity certificates used by servers, devices, and users.

Over time, organizations will need to evaluate the cryptographic algorithms used throughout their PKI hierarchy and transition vulnerable components to post-quantum alternatives. This affects:

• Certificate issuance
• Hardware security modules
• Certificate validation software
• Enrollment protocols
• Operating systems
• Client devices

Public certificate authorities face additional complexity because they must maintain compatibility across browsers, operating systems and industry standards bodies.

Info: Organizations such as the CA/Browser Forum are actively evaluating how to deploy post-quantum certificates while maintaining interoperability with existing internet infrastructure. As a result, publicly trusted post-quantum certificates are still in the early stages of adoption.

Private PKI environments, however, have greater flexibility.

Enterprise certificate authorities are not constrained by browser trust stores or public internet compatibility requirements, making private PKI a practical environment for testing and deploying post-quantum certificate hierarchies.

For organizations evaluating PKI infrastructure, the most important capability may be crypto-agility: the ability to adopt new cryptographic algorithms without rebuilding the entire PKI environment.

Many experts expect the industry to rely on hybrid certificates during the transition period, combining traditional cryptographic signatures with post-quantum signatures to maintain compatibility while introducing quantum resistance.

The NSA’s Commercial National Security Algorithm (CNSA) 2.0 guidance targets 2030 for post-quantum migration in national security systems. Broader federal guidance increasingly points toward the eventual retirement of RSA and elliptic curve cryptography for new deployments.

For many organizations, preparing for the post-quantum transition will not begin with end-user certificates or applications. It will begin with the certificate authority itself.

Cloud-Based PKI for Passwordless Security

Managing a private CA can require significant infrastructure, specialized expertise and ongoing certificate lifecycle management.

The SecureW2 cloud-based PKI is designed to help organizations deploy and manage private certificate authorities without building the entire infrastructure themselves. Organizations can use managed PKI to issue, renew and revoke certificates for users and devices while integrating certificate-based authentication into existing network and identity environments.

JoinNow Dynamic PKI and JoinNow Cloud RADIUS support certificate-based authentication for use cases such as enterprise Wi-Fi and VPN access.

For organizations looking to replace password-based network authentication or simplify certificate management at scale, a cloud-based PKI approach can provide the infrastructure needed to deploy certificate-based security without maintaining a traditional on-premises CA environment.

Schedule a free demo today and see how SecureW2 can empower your organization’s diverse security needs.

---

Frequently Asked Questions

What is the difference between a root CA and an intermediate CA?

A root CA is the top-level authority in a certificate hierarchy whose certificate is self-signed and pre-installed in trust stores. An intermediate CA receives its certificate from the root CA and handles day-to-day certificate issuance. This separation protects the root key — if an intermediate CA is compromised, its certificate can be revoked without affecting the root.

Can a certificate authority issue certificates for Wi-Fi authentication?

Yes. Private certificate authorities issue client certificates used for 802.1X authentication based on the Extensible Authentication Protocol (EAP), specifically EAP-TLS. The device presents its certificate to a RADIUS server instead of a username and password.

This approach eliminates credential theft, simplifies the user experience, and provides stronger device identity verification than password-based protocols like PEAP-MSCHAPv2.

What happens when a certificate authority is compromised?

If a CA’s private key is compromised, every certificate it has issued is potentially untrustworthy. The compromised CA’s certificate must be revoked, and all end-entity certificates it signed must be reissued by a different CA. A hierarchical model with offline root keys and short-lived intermediate CAs limits the blast radius of a compromise.

How is a private certificate authority different from a self-signed certificate?

A private CA issues certificates within a defined trust hierarchy — it has a root certificate, can have intermediate CAs, and supports full lifecycle management (enrollment, renewal, revocation). A self-signed certificate has no issuing authority and no revocation mechanism. Private CAs are auditable and scalable; self-signed certificates are not.

Do certificate authorities work with Continuous Trust architectures?

Certificate-based authentication is a core component of zero-trust (or continuous-trust) implementations. Certificates can provide non-exportable, hardware-bound device identity that cannot be phished or shared. When combined with real-time posture checks from an identity provider (IdP) or endpoint security platform, certificate-based authentication satisfies the “never trust, always verify” principle at the network layer.

What is an example of a certificate authority?

Public certificate authorities include DigiCert, Sectigo, and Let’s Encrypt. These organizations have root certificates pre-installed in major browsers and operating systems, so any certificate they issue is trusted by default.

On the private side, organizations deploy internal CAs to issue certificates for their own users, devices, and servers. Companies that want to manage a private CA without building infrastructure from scratch can use a cloud-based service such as JoinNow Dynamic PKI from SecureW2.

What is the difference between a CA and an SSL certificate?

A certificate authority is the organization that issues and validates SSL/TLS certificates; an SSL certificate is the document itself.

The CA acts as the issuing authority — verifying identity, signing the certificate, and standing behind its authenticity.

The SSL certificate is what gets installed on a server. It contains the public key, identity information, and the CA’s digital signature that browsers use to confirm the certificate is genuine.