Key Points
- Certificate Authorities (CAs) offer digital certificates that provide trust and security for online transactions, including SSL certificates, VPNs, and application security.
- CAs provide a chain of trust, providing safe communications and avoiding fraudulent activities by authenticating the legitimacy of the enterprises requesting certificates.
- SecureW2's cloud-based PKI solution simplifies digital certificate management for various security requirements.
A certificate authority (CA) is an organization that validates identities and issues digital certificates binding those identities to cryptographic key pairs. Every time a browser displays a padlock icon, a VPN tunnel negotiates a session, or a managed device authenticates to a corporate Wi-Fi network, a certificate authority is behind the transaction.
CAs are the foundation of Public Key Infrastructure (PKI), the framework that makes encrypted, authenticated communication possible across the internet and private networks. Without them, there is no reliable way to verify that a server, device, or user is who it claims to be.
This guide covers how certificate authorities work, the different types of certificate authorities, the certificate chain of trust, and how enterprise IT teams use private certificate authorities to secure Wi-Fi, VPN, and application access with digital certificates instead of passwords.
How Certificate Authorities Work
A certificate authority performs three core functions: identity validation, certificate issuance, and lifecycle management. Here’s how that works.
The Certificate Signing Request (CSR) Process
The key steps in the CSR process are as follows:
- Key pair generation. The requesting entity — a web server, user, or device — generates an asymmetric key pair (a public key and a private key). The private key stays on the device and is never shared.
- CSR submission. The entity creates a certificate signing request containing its public key and identifying information (domain name, organization name, or device identifier) and sends it to the CA.
- Identity validation. The CA verifies the information in the CSR. The depth of verification depends on the certificate type. Domain validation (DV) checks domain ownership, organization validation (OV) confirms business registration, and extended validation (EV) adds legal-entity checks.
- Certificate issuance. If validation passes, the CA signs the certificate with its own private key and returns the signed certificate to the requester.
- Lifecycle management. The CA tracks the certificate through its validity period and handles renewal, suspension, and revocation. It publishes revocation data through certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP) so relying parties can check whether a certificate is still trustworthy.
This process applies whether the CA is a public authority issuing SSL/TLS certificates for websites or a private CA issuing client certificates for enterprise Wi-Fi authentication.
What a Digital Certificate Contains
Every X.509 digital certificate includes:
- Subject — the identity the certificate represents (domain name, email, device ID)
- Public key — used by other parties to encrypt data or verify signatures
- Issuer — the certificate authority that signed the certificate
- Validity period — start and expiration dates
- Serial number — a unique identifier assigned by the CA
- Signature — the CA’s digital signature, proving the certificate has not been tampered with
- Key usage and extensions — flags indicating whether the certificate can be used for server authentication, client authentication, code signing, email encryption, or other purposes
Types of Certificate Authorities
Not all certificate authorities serve the same purpose. Understanding the differences is important for choosing the right CA for a given use case.
Root Certificate Authority
A root CA sits at the top of the certificate hierarchy. It has a self-signed certificate, meaning no higher authority vouches for it. Instead, root CA certificates are pre-installed in operating systems, browsers, and device trust stores. When a browser or operating system ships with a root CA certificate in its trust store, every certificate issued under that root is automatically trusted.
Because root CA compromise would undermine the entire hierarchy, root CAs rarely issue end-entity certificates directly. They issue certificates to intermediate CAs instead.
Intermediate Certificate Authority
An intermediate CA (also called a subordinate CA or issuing CA) receives its certificate from a root CA and uses it to sign end-entity certificates. This layered model protects the root CA, since the root key can be kept offline in a hardware security module (HSM), while intermediate CAs handle day-to-day issuance.
If an intermediate CA is compromised, its certificate can be revoked without invalidating the root or any other intermediate chains under the same root.
Public Certificate Authority
Public CAs issue certificates that are trusted by default in all major browsers, operating systems, and mobile devices. They undergo regular third-party audits (WebTrust or ETSI) and must comply with the CA/Browser Forum Baseline Requirements.
Public CAs issue three validation levels:
| Validation Level | What It Verifies | Typical Use Case |
|---|---|---|
| Domain Validation (DV) | Domain ownership only | Personal sites, blogs |
| Organization Validation (OV) | Domain + business identity | Corporate websites, SaaS apps |
| Extended Validation (EV) | Domain + legal entity + physical address | Financial institutions, e-commerce |
Public CAs are the right choice for any certificate that external users or browsers need to trust — SSL/TLS certificates for websites, publicly signed code, and S/MIME email certificates.
Private Certificate Authority
A private CA operates inside an organization and issues certificates that are only trusted by devices the organization controls. The root certificate is distributed to endpoints through MDM, Group Policy, or manual installation — it is not embedded in public browser trust stores.
Private CAs are used for:
- Wi-Fi and network authentication — 802.1X certificate-based authentication with EAP-TLS replaces passwords and pre-shared keys for WPA2-Enterprise and WPA3 networks
- VPN client certificates — authenticating remote users to VPN gateways without passwords
- Mutual TLS (mTLS) — securing internal API traffic and microservice communication
- User and device identity — issuing client certificates tied to user accounts and managed devices for web application single sign-on
Private CAs give IT teams full control over certificate policies, validity periods, key algorithms, and revocation. They are the standard approach for enterprise network access because public CAs cannot issue certificates tied to internal Active Directory or IdP identities.
SecureW2 operates as a managed private certificate authority. Organizations use SecureW2 JoinNow Dynamic PKI to create one or more private CAs, define issuance policies, and automate the full certificate lifecycle from a single cloud console. Because the platform integrates directly with identity providers like Entra ID, Okta, and Google Workspace, each certificate is bound to a verified user and device identity.
Self-Signed Certificates
A self-signed certificate is issued and signed by the same entity, with no CA involved. Self-signed certificates are useful for development, testing, and lab environments, but they provide no third-party identity verification. Browsers display security warnings for self-signed certificates, and managing them at scale across an enterprise creates operational overhead and security gaps.
For production use, a private CA is a better alternative. It provides the same internal-only trust model with proper lifecycle management, policy enforcement, and auditability.
Specialized and Cross-Certified Certificate Authorities
Some CAs operate within specific verticals. Government and military organizations run dedicated CAs (such as the U.S. DoD PKI) for classified and internal communications. Healthcare organizations use CAs that comply with HIPAA and other industry-specific security standards.
Cross-certification allows two independent CAs to recognize each other’s certificates. This is common in federated environments. For example, the Eduroam network uses cross-certification so university-issued certificates are trusted across participating institutions worldwide.
Certificate Chain of Trust Explained
A certificate chain (also called a trust chain or certification path) is the sequence of certificates that links an end-entity certificate back to a trusted root CA. Understanding the chain of trust is important for troubleshooting certificate errors and designing a CA hierarchy.
How Certificate Chain Validation Works
When a client (browser, supplicant, or application) receives a certificate, it walks the chain from bottom to top, as follows:
- End-entity certificate. The client reads the certificate presented by the server or peer. It checks the issuer field to find which CA signed it.
- Intermediate certificate(s). The client locates the intermediate CA certificate — either bundled with the end-entity certificate or cached locally. It verifies the intermediate CA’s signature on the end-entity certificate, then checks who signed the intermediate certificate.
- Root certificate. The chain ends at a root CA certificate stored in the client’s trust store. If the client recognizes the root as trusted, the entire chain is valid.
If any certificate in the chain is expired, revoked, or missing, the client rejects the connection and displays a warning.
Why the Chain Matters for Enterprise Networks
In enterprise Wi-Fi deployments using 802.1X and EAP-TLS, the RADIUS server presents its certificate to the connecting device, and the device presents its client certificate to the RADIUS server. Both sides validate the other’s certificate chain. Misconfigured chains, with missing intermediate certificates, expired root CAs, or mismatched trust stores, are one of the most common causes of Wi-Fi authentication failures.
A well-designed private CA hierarchy (root CA + one or more issuing CAs) simplifies this. The root certificate is distributed to all endpoints, the issuing CA signs both server and client certificates, and the chain is short and predictable.
Public Certificate Authority vs. Private Certificate Authority
Choosing between a public CA and a private CA depends on who needs to trust the certificate.
| Factor | Public CA | Private CA |
|---|---|---|
| Trust Scope | Trusted by all browsers and devices by default | Trusted only by devices with the root certificate installed |
| Use Case | Public websites, external-facing APIs, public code signing | Internal Wi-Fi, VPN, mTLS, device identity |
| Identity Binding | Domain and organization info | Can bind to AD/IdP user, device, department, or role |
| Policy Control | CA sets policies per CA/Browser Forum rules | Organization defines its own policies |
| Certificate Cost | Per-certificate or subscription pricing | Typically per-device or flat subscription |
| Lifecycle Automation | Varies by vendor | Fully automatable through MDM and SCEP/ACME |
| Compliance | Must pass WebTrust/ETSI audits | Org-defined; can align to NIST, HIPAA, or PCI-DSS |
A private certificate authority is the standard for securing enterprise network access, whether for EAP-TLS Wi-Fi, VPN authentication, or issuing unique device identity certificates. Public CAs cannot issue certificates containing internal user or device attributes, and their validation processes are designed for domain ownership, not enterprise identity.
Digital Certificate Use Cases Beyond SSL/TLS
Certificate authorities issue digital identities for much more than website encryption. Here are the primary use cases:
- Wi-Fi authentication (802.1X / EAP-TLS). Certificates replace passwords for connecting to WPA2-Enterprise and WPA3 networks. The client device presents a certificate to the RADIUS server, and the RADIUS server presents its certificate back. No credentials are transmitted over the air, which eliminates credential theft and over-the-air dictionary attacks.
- VPN authentication. Client certificates authenticate remote users to VPN concentrators. This removes the need for passwords or one-time codes and provides stronger identity assurance than username/password alone.
- Mutual TLS for APIs and microservices. mTLS certificates authenticate both sides of an API connection, preventing unauthorized services from accessing internal endpoints.
- Code signing. Developers sign software binaries and scripts with code-signing certificates. The signature verifies the software has not been modified since it was signed and confirms the publisher’s identity.
- Email signing and encryption (S/MIME). S/MIME certificates digitally sign and encrypt email messages, preventing tampering and ensuring only intended recipients can read the content.
- Smart card and desktop login. Certificates stored on smart cards or in a device’s TPM authenticate users to workstations and applications, replacing or supplementing passwords.
The Connection Between Certificate Authorities and PKI
While Public Key Infrastructure (PKI) provides the overarching framework of hardware, software, and policies used to manage digital identities, Certificate Authorities serve as the operational engine that executes these functions by issuing and validating the certificates themselves.
A PKI consists of:
- Certificate authority (CA) — issues, signs, and revokes certificates
- Registration authority (RA) — handles identity verification on behalf of the CA (sometimes integrated into the CA)
- Certificate repository — stores issued certificates and CRLs
- Key management — generates, stores, and protects private keys (often using hardware security modules)
- Policy framework — certificate policies (CP) and certificate practice statements (CPS) that define rules for issuance and use
Legacy PKI systems, such as Microsoft Active Directory Certificate Services (AD CS), require on-premises servers, dedicated IT staff, and manual configuration. Cloud-based PKI platforms like SecureW2 JoinNow Dynamic PKI replace this infrastructure with a managed service that handles CA operations, certificate lifecycle, and identity provider integration out of the box.
How to Choose a Certificate Authority for Enterprise Use
When evaluating a certificate authority for enterprise network authentication, Wi-Fi security, or device identity, consider these factors:
- Public vs. private. If the certificates are for internal network access (Wi-Fi, VPN, mTLS), choose a private CA. Public CAs are for external-facing trust.
- Cloud vs. on-premises. On-premises CAs (like AD CS) require dedicated servers, HSMs, patching, and backup. Cloud-based CAs eliminate that overhead.
- Identity provider integration. The CA should integrate with your IdP (Entra ID, Okta, Google Workspace) so certificates reflect real-time user and device identity.
- MDM and enrollment support. Look for native support for SCEP, ACME, and MDM-based auto-enrollment (Intune, Jamf, Kandji, Google Workspace) so managed devices receive certificates without manual steps.
- BYOD onboarding. If you support unmanaged devices, the CA platform should include a self-service enrollment portal that works across Windows, macOS, iOS, Android, and ChromeOS.
- Revocation and compliance. The CA should revoke certificates in real time when a user is disabled in the IdP or a device falls out of compliance — not on a static CRL refresh cycle.
- Scalability and uptime. For Wi-Fi authentication, the associated RADIUS service must handle peak concurrent authentications with high availability. Look for published uptime SLAs.
Secure Your Network with a Managed Private Certificate Authority
Managing certificate authority infrastructure in-house means running servers, maintaining HSMs, patching software, and staffing PKI specialists. For most organizations, this is overhead that pulls resources away from higher-priority security initiatives.
SecureW2 JoinNow Dynamic PKI is a cloud-native private certificate authority that handles CA operations, certificate lifecycle management, and identity integration as a managed service. It pairs with JoinNow Cloud RADIUS to deliver certificate-based Wi-Fi and VPN authentication without on-premises infrastructure.
- Create and manage multiple private CAs from a single cloud console
- Auto-enroll managed devices through Intune, Jamf, Kandji, and Google Workspace using SCEP and ACME Device Attestation (ACME DA)
- Onboard BYOD devices with JoinNow MultiOS — a self-service portal that provisions certificates across every major OS
- Revoke certificates in real time when users are disabled or devices fall out of compliance in Entra ID, Okta, or Google Workspace
- Detect anomalous certificate activity with CertIQ ML Anomaly Detection
Schedule a demo to see how SecureW2 replaces legacy PKI and password-based authentication with a managed private certificate authority.
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. Its 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 with 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 implementations. Certificates provide non-exportable, hardware-bound device identity that cannot be phished or shared. When combined with real-time posture checks from an IdP or endpoint security platform, certificate-based authentication satisfies the "never trust, always verify" principle at the network layer.
