Certificate Authorities and Trust
Certificate Authorities (CAs) are trusted entities that issue, manage, and revoke digital certificates. They form the root of trust in PKI, enabling verification of identities through certificate chains from root CAs through intermediate CAs to end-entity certificates.
Understanding Certificate Authorities and Trust
Certificate Authorities (CAs) are the trust anchors of Public Key Infrastructure. When your browser shows a padlock icon, it's because a CA has vouched for the website's identity by issuing a certificate signed with the CA's private key.
The trust model works like this: 1. You trust certain Root CAs (pre-installed in browsers/OS) 2. Root CAs sign certificates for Intermediate CAs 3. Intermediate CAs sign certificates for websites/users 4. You verify the chain back to a trusted root
This creates a certificate chain (or chain of trust) where trust flows from the root down to the end certificate. If any link in the chain is broken or untrusted, the entire certificate is rejected.
Why This Matters for the Exam
Certificate trust is fundamental to internet security and heavily tested on SY0-701. Questions may ask about certificate chains, what happens when a CA is compromised, or when to use self-signed versus third-party certificates.
Understanding CA trust helps with TLS/HTTPS questions, certificate warnings, and enterprise PKI design. Many real-world security issues stem from certificate trust problems.
The exam also tests practical knowledge: why browsers warn about self-signed certificates, what intermediate CAs provide, and how certificate validation works.
Deep Dive
Root Certificate Authority
The root CA is the ultimate trust anchor in a PKI hierarchy.
Root CA Characteristics:
- •Self-signed certificate (signs its own certificate)
- •Highest level of trust in the hierarchy
- •Private key is the most valuable asset
- •Often kept offline for security
- •Pre-installed in browsers and operating systems
Root CA Security:
- •Private key stored in HSM
- •Air-gapped systems (no network connection)
- •Physical security controls
- •Multi-person access controls
- •Used only to sign intermediate CA certificates
Why Offline Root CAs:
- •If a root CA is compromised, ALL certificates in its hierarchy are suspect. Keeping the root offline dramatically reduces attack surface.
Intermediate Certificate Authority
Intermediate CAs (also called subordinate CAs) sit between root CAs and end-entity certificates.
Why Use Intermediate CAs:
- •Protects root CA — Root stays offline
- •Limits damage — Compromise affects only that intermediate's certificates
- •Operational flexibility — Different intermediates for different purposes
- •Delegation — Different teams/regions can have their own intermediate
Certificate Chain Example:
- •```
- •Root CA Certificate (trusted by browser)
- • ↓ signs
- •Intermediate CA Certificate
- • ↓ signs
- •Website Certificate (www.example.com)
- •```
Chain of Trust / Certificate Chain
The certificate chain links an end-entity certificate back to a trusted root.
Validation Process:
- 1.Receive end-entity certificate
- 2.Check signature against intermediate CA's public key
- 3.Check intermediate's signature against root CA's public key
- 4.Verify root CA is in trusted store
- 5.If all signatures valid and root trusted → Certificate valid
Chain of Trust Failure:
- •Missing intermediate certificate → Chain incomplete
- •Expired certificate in chain → Chain invalid
- •Untrusted root → Chain not trusted
- •Revoked certificate → Chain invalid
Third-Party vs. Self-Signed Certificates
| Aspect | Third-Party CA | Self-Signed |
|---|---|---|
| Issued by | Trusted public CA | The entity itself |
| Browser trust | Automatically trusted | Warning displayed |
| Cost | Usually paid | Free |
| Use case | Public websites, production | Testing, internal |
| Validation | Identity verified by CA | No external verification |
| Management | CA handles revocation | Self-managed |
When to Use Self-Signed:
- •Development and testing environments
- •Internal applications (with custom trust store)
- •Lab environments
- •When CA infrastructure doesn't exist
When to Use Third-Party:
- •Public-facing websites
- •Customer-facing applications
- •Compliance requirements
- •When external trust is needed
Certificate Authority Types
Public CAs
- •DigiCert, Let's Encrypt, Sectigo, GlobalSign
- •Certificates trusted by default in browsers
- •Issue certificates for internet-facing services
- •Subject to industry standards (CA/Browser Forum)
Private/Enterprise CAs
- •Operated by organizations internally
- •Certificates trusted only within the organization
- •Used for internal applications, devices, users
- •Requires distributing root CA to endpoints
Registration Authority (RA)
The RA handles administrative tasks for the CA: • Accepts certificate signing requests • Verifies applicant identity • Approves or rejects requests • Forwards approved requests to CA
The CA focuses on signing; the RA handles verification.
Trust Store
A trust store is the collection of trusted root CA certificates: • Built into browsers (Chrome, Firefox, Safari) • Built into operating systems (Windows, macOS, Linux) • Can be customized for enterprise use • Adding certificates extends trust • Removing certificates removes trust
How CompTIA Tests This
Example Analysis
Scenario: A user visits a website and receives a certificate warning: "Certificate not trusted - unable to verify the issuer." What is the likely cause?
Possible Causes:
1. Self-Signed Certificate • Website using self-signed certificate • No chain to trusted root CA • Browser doesn't trust self-signed by default
2. Missing Intermediate Certificate • Website didn't send intermediate certificate • Browser can't build complete chain • Root CA is trusted but chain is incomplete
3. Unknown Root CA • Certificate signed by CA not in trust store • Could be private enterprise CA • Could be new or regional CA
4. Expired Certificate in Chain • Any certificate in chain has expired • Chain validation fails
Resolution Approach: • Check if certificate is self-signed • Verify intermediate certificates are served • Check if root CA is in trust store • Verify no certificates are expired
Key insight: The "chain" must be complete from end certificate to a trusted root. Any break in the chain causes trust failure.
Key Terms to Know
Common Mistakes to Avoid
Exam Tips
Memory Trick
"Root-Intermediate-End" = The Trust Sandwich
- •Root CA (top bun) — Stays protected, rarely touched
- •Intermediate CA (filling) — Does the daily work
- •End certificate (bottom bun) — What users actually see
Self-Signed Memory: Self-signed = Signing your own permission slip (Mom didn't sign it, so the school doesn't trust it)
- •Chain Validation:
- •Think of it like checking references:
- •End cert: "Intermediate CA vouches for me"
- •Intermediate: "Root CA vouches for me"
- •Root CA: "I'm pre-trusted by your browser"
- •Trust Store Memory:
- •Your browser's "approved CAs list"
- •In the list = Trusted
- •Not in the list = Warning!
Test Your Knowledge
Q1.Why do organizations use intermediate CAs instead of having the root CA sign all certificates directly?
Q2.A browser displays "Certificate not trusted" when visiting a website. The certificate is valid and not expired. What is the MOST likely cause?
Q3.When is it appropriate to use a self-signed certificate?
Want more practice with instant AI feedback?
Practice with AIContinue Learning
Ready to test your knowledge?
Practice questions on certificate authorities and trust and other Objective 1.4 concepts.