What is a Certificate Authority?

A Certificate Authority (CA) is a trusted entity that issues and digitally signs certificates binding a public key to a verified identity – a device, server, or user. CA-issued certificates let two parties establish encrypted, authenticated connections without pre-sharing a secret, underpinning TLS, IPsec, and PKI-based device authentication.

Key takeaways

• A CA issues and digitally signs certificates that verify identity.
• Certificates bind a public key to a device, server, or user.
• Root and intermediate CAs form a hierarchical chain of trust.
• Public CAs are broadly trusted; private CAs serve one organization.
• VOS devices use CA-issued or self-signed certificates for PKI authentication.

On this page: Why it matters · How it works · Types · CA & Versa · FAQ

Why is a CA important?

Without a trusted third party vouching for identity, a public key alone proves nothing – anyone can generate a key pair and claim to be anyone. A CA solves that by verifying the claimant before signing, so a relying party only has to trust the CA’s root certificate, not every endpoint it connects to. That trust anchor is what makes encrypted communication practical at internet scale: browsers and operating systems ship with a curated list of trusted root CAs, and any chained certificate is accepted automatically.

Certificate-based authentication replaces a shared secret with a verifiable, revocable credential – a compromised device gets its certificate revoked instead of every peer needing a new password. For IPsec and VPN authentication, PKI removes the need to distribute and rotate a preshared key across every endpoint.

What is a CA?

A CA sits inside a public key infrastructure (PKI) and does three jobs: verify identity, sign certificates, manage revocation. A device generates a key pair and submits a certificate signing request (CSR) with its public key and identifying details. The CA validates the request – depth ranges from confirming domain control to full organizational vetting – then signs an X.509 certificate binding the key to the identity.

CAs are usually arranged in a hierarchy: a root CA sits atop it, typically offline, and signs intermediate CAs that handle issuance. Certificates also expire or can be revoked early, checked via a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).

Types of certificate authorities

Public (commercial) CAs are trusted by default in OS and browser trust stores, making them the right choice for anything internet-facing – public websites, SaaS APIs, or services reached by devices you don’t control. Private (internal) CAs are run by an organization for its own use – internal services, VPN endpoints, device authentication – and aren’t trusted elsewhere unless the root is added to each endpoint’s trust store. Within either category, a root CA is self-signed and anchors the chain, while an intermediate CA is certified by the root and handles day-to-day issuance, limiting blast radius if compromised. A self-signed certificate skips the hierarchy entirely – fine for testing, but must be trusted manually on every device.

CA & Versa

VOS devices support certificate-based (PKI) authentication as an alternative to preshared keys for IKE and IPsec. Administrators configure a common CA – a global profile not tied to any organization – specifying the server type (ACME, CMP, CRL, GCP, KMIP, or SCEP) and, optionally, OCSP for revocation checks. Provider/customer organizations and Controller nodes reference that profile for CPE authentication; the basic setup workflow is where PKI is selected as the IKE mode and CA agents are attached to a template.

During zero-touch provisioning, “CA in Data Center” sends the branch’s CSR over the IPsec tunnel so it gets a CA-signed certificate for later tunnels. On the endpoint side, the SASE client needs the gateway’s CA certificate in its trusted root store to complete VPN registration and SSL decryption – Versa ships a default Root CA for this, which customers can replace.

Frequently asked questions

What is the difference between a CA and a CSR?

A CSR (certificate signing request) is what a device generates and submits – it contains the public key and identity details like common name. The CA verifies that and, if satisfied, signs a certificate. The CSR is the request; the CA is the issuer.

What is a self-signed certificate?

A self-signed certificate is signed by its own private key rather than a CA, so nothing trusts it automatically. It works for testing or internal setups, but every relying device must add it to its trust store manually, or connections show as untrusted.

How does a CA verify identity before issuing a certificate?

Validation depth depends on certificate type: domain-validated CAs confirm domain control, organization-validated CAs check business records, and extended-validation CAs perform deeper legal vetting. Internal or device CAs often rely on a shared enrollment secret or an automated protocol like ACME.

What happens when a certificate is revoked?

The issuing CA publishes the certificate’s serial number to a Certificate Revocation List (CRL) or answers real-time lookups via OCSP. Relying parties check one before trusting a certificate, so a revoked certificate stops being accepted immediately, even before it expires.

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

A root CA is self-signed and sits atop the trust chain, usually kept offline for security. Intermediate CAs are certified by the root and handle routine issuance, so a compromised intermediate can be revoked without invalidating the root or its other certificates.

More on CA

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about CA, these are worth looking at next.