When a browser visits an HTTPS website, it performs one critical check before showing the padlock: did a trusted Certificate Authority sign this certificate? That question is not about encryption strength. Both CA-signed certificates and self-signed certificates can use the same cryptographic algorithms and provide the same level of data encryption. The difference is entirely about trust, and understanding why a CA’s signature creates trust that a self-signature cannot is the key to understanding everything about how SSL certificates work.
This guide covers how CA signing works mechanically, how Certificate Authorities establish and maintain their position in browser trust stores, the different types of CA-signed certificates available, when self-signed certificates are acceptable, and what the choice between public and private CAs means for different deployment scenarios.
What CA Signing Actually Means
When a Certificate Authority signs an SSL certificate, it performs three things simultaneously. First, it verifies the identity of the certificate applicant to the level required by the certificate type (domain control for DV, business identity for OV, full legal entity for EV). Second, it produces a digital signature over the certificate’s contents using the CA’s own private key. Third, it adds that signature to the certificate, creating a chain of provable trust from the certificate back to the CA.
The digital signature works because of asymmetric cryptography. The CA has a private key, which it keeps highly secured and uses only for signing. It has a corresponding public key, which is contained in the CA’s own certificate. Anyone with the CA’s public key can verify the signature on any certificate the CA has signed, confirming two things: the certificate was produced by that specific CA, and the certificate contents have not been modified since signing. The CA’s public key is distributed to browsers and operating systems as part of their built-in trust stores.
This is why a self-signed certificate cannot establish the same trust. When a server signs its own certificate, it is asserting its own identity without any independent verification. A browser that receives a self-signed certificate has no way to verify that the domain name in the certificate actually belongs to the entity presenting it. Anyone can create a self-signed certificate for any domain name in seconds. A CA-signed certificate, by contrast, required the CA to verify domain control or business identity before issuing it.
The trust in a CA-signed certificate is not in the cryptography itself but in the policy and process behind the signature. The CA’s signature is cryptographically unforgeable, but what it means depends on what the CA verified before signing. A DV certificate’s signature means the CA confirmed domain control. An EV certificate’s signature means the CA confirmed the organization’s legal existence, physical address, authorized representative, and operational history. The level of identity assurance scales with the verification process.
How Certificate Authorities Get Into Browser Trust Stores
Browsers and operating systems come with a set of trusted root CA certificates built in. These root certificates are the foundation of the entire web PKI trust model. Any certificate that chains back to one of these roots is trusted. A certificate that does not chain to any trusted root produces a browser security warning.
Getting a root CA certificate into a browser or operating system trust store requires meeting stringent requirements set by the trust store operators. The major trust store operators are Google (for Chrome and Android), Mozilla (for Firefox), Apple (for Safari and iOS/macOS), and Microsoft (for Edge and Windows). Each runs its own root CA program with its own requirements, though the CA/B Forum Baseline Requirements form a common baseline that all programs enforce.
The requirements CAs must meet
To be accepted into a public trust store and maintain their inclusion, CAs must pass annual audits conducted by qualified, accredited auditors against one of several recognized audit schemes: WebTrust for Certification Authorities, ETSI EN 319 411, or equivalent. These audits verify that the CA’s operational practices match its stated policies, that its physical security meets the required standards, that its key generation and storage practices are sound, and that its certificate issuance processes correctly verify applicant identities at each validation level.
Root CA private keys must be stored in Hardware Security Modules certified to at least FIPS 140-2 Level 3. Root CAs must be kept offline or in highly restricted environments. CA infrastructure must meet specific network security requirements. Incident response procedures must exist and be tested. Personnel must undergo background checks. The CA must provide a Certificate Policy and Certification Practice Statement documenting all procedures in public detail.
Beyond the audit requirements, CAs must follow the CA/B Forum Baseline Requirements for all SSL/TLS certificates they issue. These requirements define minimum key sizes, prohibited algorithms, required extensions, maximum validity periods, domain validation methods, and dozens of other technical specifications. Violating these requirements can result in distrust by browser vendors, as has happened to several CAs over the past decade.
What happens when a CA is removed from trust stores
Browser vendors can and do remove CA certificates from their trust stores when a CA violates policies, fails audits, or is found to have issued certificates incorrectly. When Symantec was distrusted by Google in 2018, every certificate issued by Symantec or its subsidiaries had to be replaced. The distrust affected millions of websites. When TrustCor was removed by Mozilla, Google, and Microsoft in 2022 following concerns about its operations, all TrustCor-signed certificates became untrusted.
Certificate removal is the ultimate enforcement mechanism. The threat of distrust is what motivates CAs to maintain compliance with all requirements. A CA that loses browser trust loses its business model entirely, because certificates it issues after removal are worthless for public HTTPS. This accountability structure is what makes the CA trust model function.
The number of root CA certificates trusted by major browsers is relatively small, typically between 50 and 150 root certificates. Most of these belong to a handful of major CAs (DigiCert, Sectigo, GlobalSign, Entrust, Let’s Encrypt’s parent ISRG) and various government and national CAs. The actual number of SSL certificates on the internet is in the hundreds of millions, issued by the same small number of trusted roots through intermediate CAs.
Types of CA-Signed SSL Certificates
CA-signed certificates differ along two dimensions: the validation level (how thoroughly the CA verified the applicant’s identity) and the coverage scope (how many domains or subdomains the certificate covers). Understanding both dimensions helps in choosing the right certificate for any specific use case.
By validation level
| Validation Level | What the CA Verified | Who It’s For | Issuance Time | Cost Range |
| Domain Validated (DV) | That the applicant can respond to a challenge on the domain: email to a predefined address, a DNS TXT record, or a file at a URL on the domain | Personal sites, blogs, developer projects, any site needing HTTPS without business identity requirements | Minutes | Free (Let’s Encrypt) to approximately $50 per year |
| Organization Validated (OV) | Domain control plus: business registration in a recognized government registry, physical address, and a working phone number | Business websites, B2B portals, corporate intranets, any site where visitors should be able to verify the organization behind it | 1 to 3 business days | Approximately $50 to $300 per year |
| Extended Validation (EV) | Domain control plus: legal entity status, jurisdictional registration, operational existence for a minimum period, and verification that the requestor is authorized to represent the organization | Banks, financial services, healthcare, high-value e-commerce, any regulated industry where maximum trust signal is required | 3 to 7 business days | Approximately $99 to $500 per year |
The visible difference to visitors in modern browsers is in the certificate details, not in the address bar treatment. Earlier browsers displayed the organization name in a green address bar for EV certificates, but Google Chrome removed this visual distinction in 2019, and most other browsers followed. Today, DV, OV, and EV certificates all show a padlock in the address bar. Visitors who want to verify which type of certificate is in use must click the padlock and inspect the certificate details, where the Organization field and the Certificate Policies extension identify the validation level.
The security difference is in what the certificate proves. A DV certificate proves only that someone who could respond to a domain challenge requested the certificate. A phishing site using a DV certificate for a convincing lookalike domain will show a padlock. An OV certificate proves a registered business requested it. An EV certificate proves a verified legal entity with a confirmed authorized requestor obtained it. Sophisticated attackers can obtain DV certificates for convincing lookalike domains; they cannot obtain OV or EV certificates without a genuine registered business identity.
By coverage scope
| Coverage Type | What It Covers | Key Limitation | Best Use Case |
| Single Domain | One specific hostname (e.g., example.com). Most CAs include www.example.com as a second SAN automatically. | Covers only one domain; adding another requires a new certificate | A single website with no subdomains to secure |
| Wildcard | All first-level subdomains of one domain (*.example.com). Covers api.example.com, shop.example.com, etc. | Does not cover two-level subdomains (api.v2.example.com); not available for EV validation | SaaS platforms, apps with multiple service subdomains, any scenario where subdomains grow over time |
| Multi-Domain (SAN) | An explicit list of specific hostnames across different domains. Up to 250 SANs in one certificate. | Adding a new domain requires reissuing the certificate with updated SANs | Managing multiple client sites, multi-country domain portfolios, agencies |
| Multi-Domain Wildcard | Wildcard entries across multiple domains as SANs in one certificate | Largest key management risk if private key is compromised; more expensive | Enterprises with multiple brands, each with extensive subdomain use |
Public Certificate Authorities vs Private Certificate Authorities
Not all CA-signed certificates need to come from a publicly trusted CA. The distinction between public and private CAs is about the audience the certificate needs to serve.
When to use a publicly trusted CA
Any certificate that needs to be trusted by people or systems outside your organization requires a publicly trusted CA. HTTPS for a public website, an API that external developers call, a public email service using S/MIME, or any application installed on devices you do not control all need certificates from a publicly trusted CA. Because browsers and operating systems include the root certificates of publicly trusted CAs, there is nothing the user needs to install. Trust is automatic.
Publicly trusted CAs must follow the CA/B Forum Baseline Requirements and undergo annual audits. This constrains what they can issue: they cannot issue certificates with arbitrary Subject fields, arbitrary validity periods, or for IP addresses in private ranges that have no public DNS registration. These constraints protect the integrity of the public PKI but can sometimes conflict with internal infrastructure needs.
When to use a private CA
A private CA signs certificates for use within a controlled environment where you can distribute the private CA’s root certificate to every device that needs to trust it. Internal web applications accessible only from company devices, development and staging environments, service-to-service mTLS authentication within a Kubernetes cluster, and IoT device identity for devices your organization manufactured all suit a private CA well.
Private CAs offer flexibility that public CAs cannot. You can issue certificates with any Subject fields your internal systems require, any validity period (though short validity periods remain best practice for security reasons), for internal hostnames that have no public DNS record, and for private IP addresses. You are not constrained by the CA/B Forum Baseline Requirements, though following their technical best practices is still advisable for security reasons.
The operational cost of running a private CA is non-trivial. Root key security, certificate lifecycle management, CRL or OCSP publication for revocation, and audit trail maintenance all require ongoing effort. For organizations that need private PKI at significant scale, platforms like Hashicorp Vault, Microsoft Active Directory Certificate Services, AWS Private CA, and Google Cloud Certificate Manager provide managed private CA infrastructure that handles the operational complexity.
CA-Signed vs Self-Signed: When Each Is the Right Choice
The comparison between CA-signed and self-signed certificates is straightforward on the principle level: CA-signed certificates are trusted by default on all devices; self-signed certificates produce security warnings on all devices that have not been specifically configured to trust them. The practical question is when the operational complexity of getting a CA-signed certificate is unnecessary and self-signed is acceptable.
Where self-signed certificates are genuinely appropriate
The single appropriate production use case for self-signed certificates is in an environment where you control every client device and can distribute the certificate to each device’s trust store. An internal corporate application accessed only from company laptops managed through MDM can use a certificate signed by the company’s internal CA (technically a private CA, not truly self-signed), and every managed laptop trusts it because IT pushed the root certificate via group policy.
For individual developer testing environments on a single machine, a self-signed certificate where the developer manually trusts it in their local browser is acceptable and common. Tools like mkcert simplify this by creating a local CA and issuing certificates that the tool automatically installs into the development machine’s trust stores.
Where self-signed certificates cause specific problems
Browser security warnings block most visitors immediately. Modern browsers show a full-page red warning for self-signed certificates that says Your connection is not private. Studies consistently find that 70 to 90 percent of visitors leave without proceeding when they see this warning. For any site intended for public access or where visitors are not pre-briefed on the warning, self-signed certificates make the site effectively inaccessible.
API clients reject self-signed certificates by default. Most HTTP client libraries, payment gateway SDKs, and integration libraries validate TLS certificates strictly. A self-signed certificate on an API endpoint causes connection failures in these clients unless they are specifically configured to skip certificate validation, which is a significant security risk. Developers who disable certificate validation to work around a self-signed certificate in development sometimes inadvertently leave that flag enabled in production.
Compliance frameworks prohibit self-signed certificates on systems in scope. PCI DSS requires valid TLS certificates from trusted CAs on any system handling cardholder data. HIPAA guidance on encryption in transit implies trusted certificates for patient data systems. Any regulated environment handling financial, healthcare, or personal data should use CA-signed certificates from publicly trusted or properly governed private CAs.
The most dangerous outcome from self-signed certificate use is not browser warnings. It is developers and system administrators who configure their systems to skip certificate validation to avoid warning errors, then forget to re-enable validation before deploying to production. A production system that does not validate TLS certificates is vulnerable to man-in-the-middle attacks that completely defeat the encryption. The fix is always to use a properly signed certificate rather than to disable validation.
The CA/B Forum: The Body That Governs CA-Signed Certificate Standards
The CA/Browser Forum is a voluntary industry organization whose members include Certificate Authorities, browser vendors, and operating system vendors. Its Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates define the minimum standards that all publicly trusted CAs must follow when issuing TLS certificates. These requirements cover domain validation methods, certificate field requirements, key sizes, signature algorithms, validity periods, revocation infrastructure, and CA security practices.
The CA/B Forum does not have enforcement authority. Its power comes from browser vendors, who are also members. Google, Mozilla, Apple, and Microsoft can individually decide to distrust any CA that fails to meet their requirements. Because a CA without browser trust cannot issue useful certificates, the threat of distrust is sufficient to enforce compliance. Browser vendors regularly publish requirements beyond the CA/B Forum Baseline, and CAs must meet the stricter of the CA/B Forum requirements and individual browser program requirements.
The most significant recent CA/B Forum action affecting certificate holders is Ballot SC-081v3, approved in April 2025, which established a phased reduction in maximum certificate validity: 200 days from March 15, 2026; 100 days from March 15, 2027; and 47 days from March 15, 2029. This trajectory is designed to force the industry toward automated certificate management and away from the manual renewal workflows that have consistently produced certificate expiry outages.
How to Choose the Right Certificate Authority
For publicly trusted certificates, the choice between CAs is primarily about price, support, and additional features rather than the fundamental security of the certificate itself. Any certificate from any publicly trusted CA provides the same browser trust. The cryptographic properties are identical. The padlock looks the same.
Let’s Encrypt for DV at zero cost
Let’s Encrypt is a non-profit CA operated by the Internet Security Research Group (ISRG). It issues free DV certificates with 90-day validity and supports automated renewal through the ACME protocol. Certbot and other ACME clients handle renewal automatically. Let’s Encrypt certificates are trusted by all major browsers. The 90-day validity period is shorter than commercial certificates but the automated renewal makes this invisible to site operators once configured correctly.
Let’s Encrypt does not offer OV or EV certificates. It does not provide customer support for individual certificate issues. It does not offer financial warranties. For sites that need only basic DV coverage and have technical staff who can configure ACME automation, Let’s Encrypt is the correct choice at any scale.
Commercial CAs for OV, EV, and support
DigiCert, Sectigo, GlobalSign, Entrust, and GoDaddy are among the largest commercial CAs. Commercial CAs offer the full range of validation levels (DV, OV, EV), provide customer support for certificate issues, offer financial warranties ranging from tens of thousands to over a million dollars for issuance errors, issue multi-year licenses with reissuance rights, and provide certificate management platforms for organizations with large certificate inventories.
For organizations that need OV or EV validation, customer support access, warranty protection, or account management features, a commercial CA is necessary. The price difference between commercial CAs for the same certificate type is typically small. Choosing based on support quality, certificate management tooling, and whether the CA supports ACME automation for shorter validity periods is more meaningful than marginal price differences.
Comparing certificates from different CAs
When comparing CA-signed certificates across providers, the fields that matter for security are the same regardless of which CA issues the certificate: SHA-256 signature algorithm, TLS 1.2 and 1.3 support, appropriate validity period under the CA/B Forum limits, complete certificate chain including intermediates, and correct Extended Key Usage including serverAuth. Verifying these through the SSL Labs test after installation confirms the certificate is correctly configured regardless of which CA issued it.
CA-Signed vs Self-Signed: Full Comparison
| Property | CA-Signed Certificate | Self-Signed Certificate |
| Browser trust | Trusted automatically on all devices without configuration | Produces security warning on all devices not pre-configured to trust it |
| Identity verification | CA verified domain control or business identity before issuing | No independent verification; anyone can claim any identity |
| Phishing protection | Attacker cannot obtain OV/EV for a lookalike domain without genuine business identity | Anyone can create a self-signed cert for any domain name |
| Certificate Transparency | All publicly trusted CA certs are logged in public CT logs, enabling detection of unauthorized issuance | Not logged; no audit trail of issuance |
| Revocation | CA can revoke; CRL and OCSP infrastructure available | No standard revocation mechanism |
| Compliance | Required by PCI DSS, HIPAA guidance, and most security frameworks for production systems | Typically non-compliant for regulated production environments |
| API client compatibility | Accepted by default by all standard HTTP clients | Rejected by default; requires disabling certificate validation (security risk) |
| Cost | Free (Let’s Encrypt DV) to several hundred dollars per year (commercial OV/EV) | Free to generate |
| Validity period | Up to 200 days (from March 2026) for publicly trusted; longer for private CA | Any period the generator sets |
| Best for | Any production environment; all public websites; any externally accessed service | Local development with proper trust installation; isolated internal systems with managed device fleet |
Frequently Asked Questions
What is a CA-signed SSL certificate?
A CA-signed SSL certificate is an X.509 digital certificate that a trusted Certificate Authority has verified and signed. The CA confirms that the certificate applicant controls the domain or represents the business before issuing the certificate. The CA’s digital signature, computed using the CA’s private key, is attached to the certificate. Browsers and operating systems come with the CA’s public key in their trust stores, allowing them to verify the signature and trust the certificate automatically. This is how HTTPS connections establish trust without any prior arrangement between the visitor’s device and the website.
What is the difference between a CA-signed and a self-signed certificate?
Both types are X.509 digital certificates and both provide the same TLS encryption for data in transit. The difference is in identity verification and trust. A CA-signed certificate was verified by an independent Certificate Authority before issuance, and the CA’s signature allows browsers to trust it automatically. A self-signed certificate was signed by the entity using it, with no independent verification. Browsers cannot distinguish a legitimate self-signed certificate from one created by an attacker impersonating a site, so they display a security warning for all self-signed certificates on devices that have not been specifically configured to trust the certificate.
Can I get a free CA-signed SSL certificate?
Yes. Let’s Encrypt issues free DV certificates signed by the ISRG Root X1, which is trusted by all major browsers. Let’s Encrypt certificates have 90-day validity and require automated renewal using the ACME protocol, which Certbot and other clients handle automatically. Many hosting providers also offer free SSL certificates through Let’s Encrypt integration. The free certificates provide identical encryption to paid certificates. If you need OV or EV validation, customer support, or specific warranty coverage, you need a paid commercial certificate.
How do I check whether my SSL certificate is CA-signed and trusted?
Run your domain through the SSL Labs test at ssllabs.com/ssltest. The Certification Paths section shows the complete certificate chain, confirming that the certificate chains to a trusted root CA. In Chrome, click the padlock in the address bar, then Connection is secure, then Certificate is valid. The Details tab shows the Issuer field, which identifies the CA, and the Certificate Hierarchy section shows the chain. If the certificate is self-signed, the Issuer and Subject will show the same entity, and the chain will have only one certificate with no CA above it.
Is a private CA certificate the same as a self-signed certificate?
No, though they are often confused. A self-signed certificate is one where the subject and the issuer are the same entity, the certificate holder signed their own certificate. A private CA certificate is one signed by an internal Certificate Authority that the organization controls. The private CA is a separate entity from the certificate holder: the CA signed the certificate, but the CA is not the same as the website or service using the certificate. A private CA certificate chain has multiple links (root CA, possibly intermediate CAs, and the end-entity certificate), just like a publicly trusted CA certificate. Private CA certificates produce browser warnings on devices that do not have the private CA’s root certificate in their trust store, because the private root is not in the public browser trust programs.
What happens to my CA-signed certificate when the CA is distrusted?
When a CA is removed from browser trust stores, all certificates that chain to that CA’s root become untrusted. Browsers show security warnings for sites using those certificates, and visitors cannot proceed without bypassing the warning. The certificate itself has not changed, but the trust chain it depended on is broken. If your CA is distrusted, you must replace your certificate with one from a trusted CA before the distrust takes effect. CA distrust events are usually announced with several months of lead time, providing a window to replace affected certificates. Monitoring services can alert you when certificates from specific CAs in your inventory are from CAs under distrust review.
