What Is a Certificate Authority? A Complete Guide to Digital Trust

Every encrypted connection you rely on, from a bank login to an API call between microservices, depends on a single question being answered correctly: is the entity on the other end really who it claims to be? Certificate authorities exist to answer that question. They are the trust anchors that make authenticated, encrypted communication possible at scale.

This guide explains what a certificate authority is, how the issuance process works, the trust hierarchy that keeps the system secure, and how to decide which type of CA fits your organization’s needs.

What is a certificate authority?

A certificate authority is a trusted entity that verifies the identity of users, machines, organizations, services, etc., then issues digitally signed certificates that prove those identities. In the context of public key infrastructure, the CA’s primary function is to issue and revoke certificates while supporting certificate management workflows, including request validation and publishing.

At its core, a CA binds an identity to a cryptographic key pair. When a CA issues a certificate, it is making a verifiable statement: “I have confirmed that this public key belongs to this entity.” Anyone who trusts the CA can then trust that statement, which is what allows strangers to establish secure connections without any prior relationship.

CAs can refer to both the organization that vouches for identities and the server infrastructure used to issue and manage certificates. Whether operated by a global provider or deployed internally by an enterprise IT team, the function is the same: authenticate an entity, issue a signed certificate, and manage that certificate through its lifecycle.

Why certificate authorities are necessary

Certificate authorities exist to efficiently solve a fundamental problem in public-key cryptography: how do you know that a public key actually belongs to the entity it claims to belong to?

Public-key cryptography lets two parties communicate securely without sharing a secret in advance, but it has a critical weakness. If you receive a public key claiming to be from your bank, nothing about the key itself proves that claim. An attacker could present their own key, impersonate the bank, and intercept your entire connection. The cryptography guarantees the math, but not the identity behind it.

Without a trusted third party to verify identities, organizations face serious risks:

• Man-in-the-middle attacks: An attacker intercepts communication between two parties, impersonating each side to the other.
• Identity impersonation: Malicious actors present fraudulent credentials that appear legitimate, gaining unauthorized access to systems and data.
• Data interception: Sensitive information transmitted over unverified connections can be captured and exploited.

CAs solve these problems by acting as trusted third parties that vouch for the binding between an identity and a public key. The CA verifies that an entity is who it claims to be, then issues a digitally signed certificate attesting to that binding. Because the CA signs with its own private key, anyone can verify the certificate’s authenticity using the CA’s well-known public key. You do not have to trust the entity presenting the certificate; you only have to trust the CA that vouched for it.

This model is what makes trust scalable. Rather than every party needing to establish trust individually with every other party (an impossible problem at internet scale, or even within the modern enterprise), everyone anchors trust in a relatively small set of CAs. Operating systems and browsers ship with a preinstalled set of trusted root CAs, and that shared foundation lets billions of connections happen securely every day.

How a certificate authority works

The certificate issuance process follows a well-defined sequence. Understanding each step clarifies how CAs establish and verify trust.

Step 1: Generate a key pair. 
The applicant creates a public and private key pair. The private key remains secret and never leaves the applicant’s control.

Step 2: Create a Certificate Signing Request (CSR). 
The applicant builds a CSR containing their public key and identifying information (such as a distinguished name for an X.509 certificate). The CSR is signed using the applicant’s private key to prove possession.

Step 3: Submit the CSR to the CA. 
The applicant sends the CSR to the CA along with any required proof of identity. The CA may require legal documentation, domain ownership verification, or organizational validation depending on the certificate type.

Step 4: The CA validates the request. 
The CA reviews the CSR, verifies the applicant’s identity, and confirms that the request meets its issuance policies.

Step 5: The CA signs and returns the certificate. 
Once validated, the CA signs the certificate with its own private key and returns the completed certificate to the applicant. The certificate can now be deployed on servers, devices, or applications.

In IoT ecosystems, this process is adapted for device manufacturing. In some instances, the device’s Root of Trust generates an ECC key pair and CSR, which is submitted to the vendor’s PKI. The Product Attestation Intermediate (PAI) signs the request and issues a Device Attestation Certificate (DAC) that is securely stored on the device.

The role of public and private keys

Asymmetric cryptography underpins the entire CA process. Every CA maintains its own key pair: a private key used to sign certificates and a public key distributed widely so anyone can verify those signatures.

When a CA issues a certificate, it creates a digital signature by encrypting a hash of the certificate contents with its private key. Any recipient can then verify that signature using the CA’s public key. If the verification passes, the signature is valid, and the certificate can be trusted.

This mechanism ensures that certificates cannot be forged. Only the CA possessing the private key can produce a valid signature, while anyone with the public key can verify it.

The certificate authority trust hierarchy

The CA trust model is built on a layered hierarchy that balances security with operational flexibility. Trust chains from a single root CA down through intermediate authorities to the certificates installed on endpoints.

Root certificate authorities

The root CA sits at the highest level of the hierarchy and serves as the trust anchor. For an end-entity certificate to be trusted, it must chain up to a root CA that is embedded in the operating system, browser, or device validating the certificate.

Root CAs are heavily secured and typically kept offline. Their private keys are stored in GSA-grade facilities with strict controls. Because compromising a root CA would undermine every certificate in its hierarchy, root CAs rarely issue certificates directly. Instead, they delegate that responsibility to subordinate CAs.

Intermediate, subordinate, and issuing certificate authorities

Intermediate CAs operate between the root CA and end-entity certificates. Their primary purpose is to define and authorize the types of certificates that can be requested from the root CA. They are also known as Subordinate CAs, since their own certificate has been signed by another CA.

Organizations commonly deploy separate subordinate CAs for different purposes. On public hierarchies, for example, TLS and S/MIME subordinate CAs must be separated. Other common configurations include separate subordinates for different geographic locations, or one subordinate for certificates using ECC keys and another for RSA keys.

An intermediate CA dedicated to sign certificates for end users (end-entities) are known as issuing CAs. An issuing CA is, therefore, almost always a subordinate CA, since root CAs seldom issue certificates to end users.

End-entity certificates

End-entities are the end users alluded above. End-entity certificates are the final link in the trust chain, and are also known as the leaves of the PKI heirarchy. These are the certificates installed on servers, machines, cryptographic hardware, and devices. They represent the identity of a specific endpoint and enable that endpoint to establish authenticated, encrypted connections.

Every end-entity certificate chains back through one or more intermediate CAs to a trusted root CA. Verifying this chain is how systems confirm that a certificate is legitimate.

Types of certificate authorities

Public certificate authorities

Public CAs are trusted by default in browsers, operating systems, and devices. They issue certificates for public-facing websites, applications, and services where external users and customers need to verify the server’s identity without any manual configuration.

Organizations rely on public CAs (such as DigiCert) for TLS certificates that secure customer-facing interactions. Public CAs operate under strict external governance, including the CA/Browser Forum Baseline Requirements, and their certificates are logged via Certificate Transparency to maintain accountability.

Private certificate authorities

Private CAs are operated internally by organizations to issue certificates for use cases that do not require public trust. Typical uses of private CAs include:

• Secure communications between internal services, including containerized and API-connected cloud environments
• Intranet sites
• Virtual Private Network (VPN) certificate or wireless authentication
• Device identification
• Workloads and container identification
• IoT (Internet of Things) projects

With a private CA, the organization becomes its own trust anchor. It decides what identities are valid, issues certificates to its own services and devices, and controls the entire trust hierarchy. This is why a private CA can authenticate machine-to-machine communication that no public CA would ever vouch for, enabling zero trust architectures across internal networks.

How to choose between a public and private CA

The decision between public and private CAs comes down to who needs to trust the certificate.

Dimension	Public CA	Private CA
Who trusts it	Universally trusted via preinstalled root stores in browsers, OSes, and devices	Trusted only by systems explicitly configured to trust your root
Primary use case	User-facing services: public websites, customer APIs, email servers	Internal infrastructure: mTLS, service-to-service auth, VPNs, device/workload identity
Trust anchor	The public CA (external third party)	Your organization
Identity validation	Mandatory domain/organization validation per external rules	Whatever identity scheme you define (internal hostnames, service accounts, device IDs)
Governing rules	CA/Browser Forum Baseline Requirements, mandatory standards	Your own internal policy
Certificate lifespans	Externally dictated, trending steadily shorter	Set to whatever fits your environment
Public logging	Logged via Certificate Transparency	Nothing logged publicly
Cost model	Per-certificate pricing (or free tiers like Let’s Encrypt)	No per-certificate cost; you bear infrastructure/operational cost
Scale economics	Impractical for thousands of short-lived certs	Built for high-volume internal issuance
Control	Limited, bound by external policy	Full control over policy, issuance, and hierarchy

The pattern: a public CA trades control for universal trust and offloaded operations, while a private CA trades operational burden for full control and internal-scale economics. Most organizations run both, one for each trust boundary.

Certificate authority types by certificate format

Beyond the public and private distinction, CAs can also be categorized by the types of certificates they issue.

X.509 certificate authorities

X.509 is the most common CA type, used for secure email, login, web authentication, VPN, and more, as defined in RFC 5280. X.509 certificates are the standard format for SSL certificates and form the backbone of most PKI deployments. They define the structure of digital certificates, including distinguished names, validity periods, extensions, and the cryptographic algorithms used for signing.

CVC certificate authorities

CVC CAs issue Card Verifiable (CV) certificates, which are specialized certificates designed for EU EAC (Extended Access Control) ePassports. These certificates enable secure electronic identity verification for border control and government identification systems.

SSH certificate authorities

SSH CAs issue certificates in a format specific to the SSH protocol, providing an alternative to traditional SSH key-based authentication. Rather than distributing individual public keys to every server, organizations can use an SSH CA to issue short-lived certificates that are automatically trusted by any server configured to recognize the CA.

C-ITS enrollment certificate authorities

C-ITS (Cooperative Intelligent Transport Systems) certificates use an EU-defined format for Vehicle-to-Everything (V2X) communications. These specialized certificates support secure communication between vehicles, infrastructure, and traffic management systems, playing a critical role in automotive and transportation security.

Certificate authority compliance and security standards

CAs must adhere to rigorous security and compliance standards to maintain trust. The frameworks governing CA operations span industry regulations, technical standards, and physical security requirements.

Industry and regulatory standards

Certificate Authorities operate with compliance to multiple frameworks depending on their deployment context:

• DORA (Digital Operational Resilience Act): Applies to financial sector entities across the EU, mandating digital resilience measures including PKI security.
• NIS2 (Network and Information Security Directive): Expands cybersecurity requirements across essential and important entities in the EU.
• HIPAA (Health Insurance Portability and Accountability Act): Requires encryption and identity controls for healthcare data, directly affecting how CAs are deployed in medical environments.
• PCI/DSS (Payment Card Industry Data Security Standard): Mandates encryption for cardholder data, requiring robust CA operations for payment processing systems.
• FedRAMP (Federal Risk and Authorization Management Program): Sets security standards for cloud services used by U.S. federal agencies.
• FIPS 140-2, 140-3: FIPS 140-2 defines security requirements for cryptographic modules, including the hardware and software used by CAs for key generation and storage. these requirements continue and, in some ways, become stricter in FIPS 140-3.

CA/Browser Forum Baseline Requirements

The CA/Browser Forum sets standards that all publicly trusted CAs must follow. These Baseline Requirements govern certificate issuance practices, validation procedures, and technical constraints.

One notable requirement involves certificate serial number entropy. Conforming certificates must contain at minimum 64 bits of fully random information in their serial numbers. This serves as a defense against hash-based collision attacks on the certificate signature, strengthening the PKI against preimage attacks.

Hardware security modules and key protection

CAs integrate with hardware security modules (HSMs) for secure key storage and cryptographic operations. HSMs provide tamper-resistant environments where private keys are generated, stored, and used without ever being exposed in plaintext.

Infrastructure maintenance for high-security CA deployments includes offline root CAs hosted in physically secured facilities with strict access controls, environmental monitoring, and audit logging. This layered approach ensures that even if operational systems are compromised, the root trust anchor remains protected.

Certificate authority protocols and technical integration

CAs support a range of enrollment and management protocols that enable automated certificate operations at scale. The right protocol depends on the environment, the devices involved, and the level of automation required.

Common enrollment protocols

• SCEP (Simple Certificate Enrollment Protocol): Widely used for device enrollment, particularly in network infrastructure and mobile device management. SCEP enables devices to request and receive certificates with minimal manual intervention.
• CMP (Certificate Management Protocol): A standards-based protocol that supports the full certificate lifecycle, including issuance, renewal, revocation, and key recovery.
• EST (Enrollment over Secure Transport): A modern, TLS-based enrollment protocol designed to replace SCEP with improved security. EST uses HTTPS for transport and supports certificate renewal and re-enrollment.
• ACME (Automatic Certificate Management Environment): Enables fully automated certificate issuance and renewal, most commonly associated with Let’s Encrypt but increasingly adopted for internal PKI automation.
• Microsoft auto-enrollment: Integrates certificate deployment with Active Directory, allowing certificates to be issued automatically to domain-joined machines and users based on Group Policy settings.

Certificate formats

The X.509 certificate format (defined in RFC 5280) is the most common structure for digital certificates. An X.509 certificate includes fields such as the subject’s distinguished name, the issuer’s distinguished name, validity period (not before and not after dates), the subject’s public key, a serial number, and the CA’s digital signature. Other common certificate formats include OpenPGP certificates, OpenSSH certificates, CVC certificates, etc.

The CSR (Certificate Signing Request) that initiates the issuance process includes identifying details about the applicant (such as a distinguished name) and the applicant’s preferred public key. The CSR must be signed with the applicant’s private key to prove key possession.

Certificate authorities and emerging use cases

IoT device identity

In IoT ecosystems, CAs provide the foundation for secure device identity. Each device receives a unique certificate during manufacturing or provisioning, enabling mutual authentication between devices and services.

A typical instantiation of the CA heirarchy within an IoT ecosystem looks as follows: A Root CA (kept offline) issues certificates to a Product Attestation Authority (PAA), which delegates to Product Attestation Intermediates (PAIs) for different product types. Each PAI issues a unique Device Attestation Certificate (DAC) to every physical device. The device’s Root of Trust generates an public/private key pair and CSR, which the vendor PKI signs and returns as the DAC.

This approach ensures that every connected device has a verifiable, unique identity anchored in a trusted certificate chain, from the individual device all the way back to the vendor’s root CA.

Post-quantum cryptography readiness

As quantum computing advances, CAs must prepare for the transition to quantum-resistant algorithms. Current public-key algorithms (RSA, ECDH, ECDSA, etc) are vulnerable to attacks by sufficiently powerful quantum computers, which means the certificates that CAs issue today could eventually be compromised.

Modern CA platforms already support post-quantum cryptography algorithms. For example, EJBCA supports post-quantum signing algorithms such as DILITHIUM5, which can only be used in conjunction with DILITHIUM5 keys. Hybrid certificate issuance, which combines classical and quantum-resistant signatures in a single certificate, is also available, enabling organizations to achieve crypto-agility ahead of the quantum threat.

How Keyfactor can help

Managing certificate authorities at scale requires more than manual processes. Keyfactor provides a unified platform for organizations operating public CAs, private CAs, or both.

• EJBCA Enterprise: A full-featured, scalable CA and PKI platform that supports X.509, CVC, SSH, and C-ITS certificate types. EJBCA provides built-in security controls, automation, and lifecycle management, with support for multiple CAs, validation authorities, and registration authorities within a single deployment.
• Keyfactor Command: Centralized visibility and management across all CAs in a single pane of glass. Command integrates public CAs (like DigiCert), Microsoft CAs, and internal private CAs, providing real-time certificate inventory, automated scanning, monitoring, and one-click renewal capabilities. It also integrates post-quantum cryptography CAs, including those using MLDSA-65 and hybrid algorithms, providing organizations with a path to quantum readiness within their existing CA infrastructure Administrators can configure scan schedules, set alerting thresholds for burst issuance, and manage certificate lifecycles across the entire organization.
• PKI as a Service: Combines managed PKI and certificate automation, reducing the operational burden of running internal CA infrastructure while maintaining full certificate lifecycle control.
• Crypto-agility and post-quantum readiness: Support for hybrid certificates and quantum-resistant algorithms ensures organizations can transition their CA infrastructure as cryptographic standards evolve.

Request a demo to see how Keyfactor can modernize your CA operations and prepare your PKI for the future.