Certificate Authorities

Introduction: The need for Certificate Authorities

In earlier articles, we have seen how digital certificates are one of the fundamental building blocks of Public Key Infrastructure (PKI). Certificates are used in multiple ways – for establishing identity, or for enabling secure web communication, or for proving ownership and integrity of software through code signing.
However, the key question that arises is: while the certificate helps to establish the reliability of some other information (such as identity or proof of ownership for software), who vouches for the reliability of the information in the certificate itself? How does a user know whether a certificate can be trusted or not and whether the public key in the certificate actually belongs to the indicated owner?

This is where a Certificate Authority or Certification Authority (CA) comes in. The CA is an entity that issues digital certificates, but does so only after performing a set of validations of the organization applying for the digital certificate – for example, confirming that the organization is the actual owner of the public key that will be included in the Digital Certificate.

Examples of some of the well-known CAs include Comodo, Symantec, GoDaddy, GlobalSign, DigiCert, Let’s Encrypt, and Entrust. CAs are at the heart of PKI as a trusted third-party entity: they are trusted both by the certificate applicants, as well as the users (devices, operating systems, browsers) who receive the certificate and decide whether to proceed with the transaction or not.

Quick Answer: What Is a Certificate Authority?

A Certificate Authority (CA) is a trusted third-party entity that issues digital certificates after validating the identity of the applicant. CAs perform Domain, Organization, or Extended Validation, sign certificates with their private key, and maintain a trust hierarchy rooted in a Trusted Root Certificate. Browsers and operating systems trust CAs that meet CA/Browser Forum security standards, and can revoke trust from those that don’t.

Executive Summary

Certificate Authorities are the trusted third parties that make PKI work: they validate applicants and sign the certificates that let users trust a public key. This post covers what a CA does, the four core functions from receiving a CSR to revoking certificates, the three validation levels (DV, OV, EV), how trust hierarchies and root certificates anchor the whole system, why CA security matters so much, and the role of the CA/Browser Forum in setting industry-wide standards. It also covers a practical glossary and decision table for understanding CA concepts and how this connects to broader certificate lifecycle management.

Who Should Care About Certificate Authorities

How CAs validate and issue certificates touches PKI operations, security architecture, platform management, and compliance. Here is what each role should do.

PKI Administrators

Know which validation level (DV, OV, or EV) each certificate request requires, and track every CA relationship the organization depends on so no certificate authority goes unmonitored.

Security Architects

Design PKI architecture around trust hierarchies and root certificate placement, and evaluate a CA’s security posture, including HSM use, before relying on it for issuance.

Platform Teams

Keep root and intermediate certificates current in device operating systems and browsers, and respond immediately if a CA’s root certificate is ever removed from a trust store.

Compliance Teams

Confirm that certificates used for regulated transactions meet the validation level required by policy, and document that CAs in use comply with CA/Browser Forum Baseline Requirements.

CISOs

Treat CA trust as foundational risk: a compromised or de-trusted CA can invalidate every certificate it issued, so sponsor visibility into which CAs the organization actually relies on.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses exceeding $250,000, with 37.5% of those incidents tied specifically to expired certificates. Every certificate issued by a CA is subject to this same expiry risk regardless of validation level.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. This directly affects how frequently organizations must interact with their CAs for reissuance, making CA relationship management and automation increasingly important.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. CAs will need to support these new signature algorithms as organizations migrate, making a CA’s crypto-agility roadmap an increasingly important selection criterion.

Functions of a CA

The functions of a typical CA include receiving requests for digital certificates, processing these requests including performing background verifications of the applicants, approving & rejecting the requests, actually issuing the certificates, and managing and revoking certificates. These are explained below.

1. Receive a Certificate Signing Request (CSR): The applicant who requires a digital certificate generates a public-private key pair and sends the public key to the CA along with basic information that is needed for the CA to issue the certificate.
2. Process the information in the CSR: The CA processes the information in the CSR, including the type of certificate needed and the details about the applicant company. Depending on the type of certificate needed, the CA performs a set of validations, as described in the next section.
3. Approve/Reject the CSR and issue the certificate: Once the validations are complete, the CA issues the certificate. The CA signs the certificate with its private key, providing a ‘seal of authenticity’ for the certificate and the public key of the certificate owner.
4. Manage and Revoke certificates: The CA also manages certificates – for example, renewing expired certificates based on requests from certificate owners. In case the private key of a certificate owner is compromised, the CA can invalidate or revoke a certificate. Revocation helps to alert users that the certificate cannot be trusted anymore and helps to limit the impact from a breach.

Validations performed by a CA

Any CA performs a set of validations before issuing certificates. The types of validations performed are:

• Domain Validation (DV): This involves checks to make sure that the organization (or person) applying for a digital certificate (for a domain) is the actual owner (or represents the owner) of the domain name. No identity checks are performed in this case.
• Organization Validation (OV): This includes additional checks (apart from domain name ownership verification) such as validating the organization itself and checking whether the applicant is authorized by the organization to apply for a certificate.
• Extended Validation (EV): This involves the highest levels of validations, including detailed vetting of the company applying for the certificate such as checking the registered name of the company, place of business, and other legal details.

Trust Hierarchies & Root Certificates

Each CA has a master certificate called a Trusted Root Certificate, which is the parent of all digital certificates issued by that CA and serves as the ultimate basis of trust in the CA itself. Root certificates are typically pre-installed in the device operating system and in browsers. Root certificates are used to create intermediate certificates, these intermediate certificates are used by the CA to actually sign the digital certificates being issued by the CA.

This “chaining” of certificates to a parent going back all the way to the root certificate of that CA, is also known as a trust hierarchy or certificate hierarchy. This hierarchical approach is helpful to scale out PKI infrastructure overall – with a parent CA authorizing other CAs to issue certificates, by signing the root certificate of the other CA. Whenever needed, certificates issued by the other CA can be traced back to the root certificate of the parent CA.

CA Security

Since the CA and its root certificate are the foundation of trust for the entire PKI infrastructure, CAs need to have significantly higher levels of security as compared to any other organization. These include physical controls, logical controls, and the use of Hardware Security Modules (HSMs) for key management. In case a CA fails to meet or exceed the expected security standards, its root certificate could be removed from the system repository by browsers, operating systems, and device vendors.

This will result in an immediate warning to the end user that the certificate for the current transaction cannot be trusted and is likely to influence the user to abort the transaction, resulting in an adverse business impact. To standardize the security requirements that a CA must adhere to, industry bodies such as the CA/Browser forum have been formed.

CA/Browser Forum

This is a voluntary group of CAs and browser vendors that have come together to form an industry body with the aim of developing guidelines for CA trust systems. This includes recommendations for validation procedures, key lengths, key management, and encryption algorithms. Two major guidelines from the forum include Baseline Requirements (BRs) and Extended Validation (EV) Guidelines.

Baseline Requirements are the fundamental rules that any CA has to adhere to for issuing any type of digital certificate. EV guidelines provide additional security, technical and authentication requirements that a CA must adhere to in order to issue EV certificates.

Certificate Authorities Glossary

Quick, extractable definitions for the terms used throughout this post.

Term	Definition
Certificate Authority (CA)	A trusted third-party entity that issues digital certificates after validating the applicant’s identity or domain ownership.
Certificate Signing Request (CSR)	A request containing an applicant’s public key and identifying information, submitted to a CA to obtain a digital certificate.
Domain Validation (DV)	The most basic CA validation level, confirming only that the applicant controls the domain, with no identity checks.
Organization Validation (OV)	A CA validation level that verifies the requesting organization’s existence and the applicant’s authorization to request a certificate.
Extended Validation (EV)	The highest CA validation level, involving detailed legal and business vetting of the applicant organization.
Trusted Root Certificate	A CA’s master certificate, pre-installed in operating systems and browsers, that anchors trust for every certificate the CA issues.
CA/Browser Forum	A voluntary industry body of CAs and browser vendors that sets Baseline Requirements and EV Guidelines for certificate issuance.

Certificate Authority Decision Table: Concept, When It Matters, Example, and Implementation

Concept	When It Matters	Example	Implementation Consideration
Validation level (DV/OV/EV)	Choosing a CA and certificate type for a public-facing service	A bank requests an EV certificate; a basic marketing site uses a DV certificate	Match validation level to the sensitivity of the transaction, not just cost or speed of issuance
Trust hierarchy placement	Designing or auditing a PKI architecture with intermediate CAs	An enterprise root CA signs an intermediate CA used only for internal device certificates	Keep root CAs offline and protected; use intermediates for day-to-day issuance
CA security posture	Selecting or continuing to rely on a public or private CA	A CA loses browser trust after failing to meet Baseline Requirements	Evaluate a CA’s HSM use, audit history, and CA/Browser Forum compliance before relying on it
Certificate revocation	A certificate’s private key is suspected of compromise	A CA revokes a certificate and publishes it to a CRL or OCSP responder	Confirm revocation checking is enabled wherever the certificate is validated
Validity period changes	Planning renewal cadence as CA/Browser Forum rules shorten validity	A 47-day certificate lifecycle requires far more frequent renewal than a 200-day one	Automate certificate issuance and renewal rather than relying on manual CA interaction

Certificate Lifecycle Management and PKI Modernization

Managing relationships with one or more CAs is a core part of any PKI modernization program. CertSecure Manager automates certificate discovery, issuance, and renewal across multiple CAs, including certificate automation that keeps pace with shrinking validity windows.

Organizations that want a managed, cloud-hosted CA without operating that infrastructure entirely in-house can rely on PKI-as-a-Service. Building a machine identity inventory and running certificate discovery through CBOM Secure helps surface every certificate issued by every CA already in use across your environment, and completing a PQC readiness assessment ensures your CA relationships have a migration path toward crypto agility and post-quantum signature algorithms. Encryption Consulting’s PQC Center of Excellence provides guidance on sequencing that migration.

For more on why certificate automation matters across the environment, see our Education Center articles on the stages in a certificate’s lifecycle and how to avoid certificate outages. For related content, see Why to fix expired SSL certificates? and Introduction to Certificate Extension – Basic Constraints.

Measuring Success and Ongoing Audits

Track how many CAs the organization actively relies on, whether each meets the validation level required by policy, and how quickly a revoked or expiring certificate can be replaced. Audit CA trust relationships and certificate inventories on a recurring basis, quarterly for policy-driven factors like CA/Browser Forum validity requirements, and continuously for certificate expiry, so trust in a CA is never assumed rather than verified.

Last updated: August 2026. Last verified: August 2026. This post follows a 6-month refresh cadence as an evergreen explainer of Certificate Authority fundamentals, with quarterly checks against evolving certificate validity and CA/Browser Forum policy.

Frequently Asked Questions

What is the main takeaway from Certificate Authorities?

A Certificate Authority is the trusted third party that makes PKI trustworthy: it validates applicants, issues signed certificates, and anchors trust through a root certificate that browsers and operating systems recognize.

Why does this matter for enterprise PKI teams?

PKI teams need to select the right validation level for each certificate and monitor the security posture of every CA they depend on, since a de-trusted CA can invalidate every certificate it has issued.

What risks increase if this topic is handled manually?

Manually managing CA relationships increases the risk of missing a validation-level mismatch, failing to notice a CA’s declining security posture, or missing a certificate renewal as validity periods shrink.

Which teams should own this change?

Security architects design trust hierarchies and evaluate CA security, platform teams keep root and intermediate certificates current, PKI administrators track validation levels and CA relationships, and compliance teams confirm validation levels meet policy.

How does this connect to certificate lifecycle management?

Every certificate a CA issues needs the same discovery, renewal, and revocation discipline; treating CA relationships as part of one certificate lifecycle management program prevents any certificate from being overlooked.

How should organizations measure success?

Track how many CAs the organization actively relies on, whether each meets the required validation level, and how quickly a revoked or expiring certificate can be replaced.

What should be audited or monitored regularly?

Regularly audit CA trust relationships and certificate inventories across all validation levels, and confirm revocation checking is enabled wherever certificates are validated.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Organizations using multiple CAs across cloud and on-premises environments need centralized visibility into every trust hierarchy in use, since a certificate from an untracked CA is just as likely to expire or be revoked unnoticed.

What common mistakes should teams avoid?

Common mistakes include using a lower validation level than a transaction warrants, failing to monitor a CA’s ongoing security posture, and not automating renewal as CA/Browser Forum validity periods shrink.

What should be refreshed quarterly?

Review validation-level requirements against current transaction sensitivity, confirm all CAs in use still meet current CA/Browser Forum Baseline Requirements, and re-verify certificate validity periods against the latest validity schedule.