Certificate Management
The lifecycle management of digital certificates including generation of Certificate Signing Requests (CSR), issuance, revocation through CRL and OCSP, wildcard and SAN certificates, expiration monitoring, and renewal processes.
Understanding Certificate Management
Certificate management encompasses the entire lifecycle of digital certificates—from creation through expiration or revocation. Poor certificate management leads to outages (expired certificates) and security incidents (compromised certificates not revoked).
The certificate lifecycle: 1. Request — Generate CSR with key pair 2. Issuance — CA validates and issues certificate 3. Usage — Certificate deployed and used 4. Monitoring — Track expiration and validity 5. Renewal/Revocation — Extend or terminate certificate
Organizations often manage thousands of certificates across servers, devices, and users. Automated certificate management is essential to prevent human error and ensure timely renewals.
Why This Matters for the Exam
Certificate management is frequently tested on SY0-701 because it's where theory meets practice. Questions cover CSR generation, revocation mechanisms (CRL vs. OCSP), certificate types (wildcard, SAN), and lifecycle management.
Real-world certificate incidents are common: major outages from expired certificates, security breaches from unrevoked compromised certificates, and compliance failures from poor tracking. Understanding management prevents these issues.
The exam tests both concepts (what is a CSR?) and scenarios (certificate expires in 30 days, what should you do?).
Deep Dive
Certificate Signing Request (CSR)
A CSR is the first step in obtaining a certificate from a CA.
CSR Contents:
- •Subject information (organization, domain, location)
- •Public key (generated locally)
- •Signature (proves possession of private key)
CSR Generation Process:
- 1.Generate key pair locally (public + private)
- 2.Create CSR containing public key and subject info
- 3.Sign CSR with private key
- 4.Send CSR to Certificate Authority
- 5.CA validates identity and issues certificate
- 6.Private key never leaves your system
Key Point: The private key is generated locally and never sent to the CA. The CSR only contains the public key.
Certificate Revocation
Revocation invalidates a certificate before its expiration date.
When to Revoke:
- •Private key compromised
- •Certificate issued in error
- •Employee leaves organization
- •Domain ownership changes
- •CA compromise
Certificate Revocation List (CRL)
A CRL is a list of revoked certificates published by the CA.
How CRL Works:
- 1.CA maintains list of revoked certificate serial numbers
- 2.CRL published periodically (daily, hourly)
- 3.Clients download CRL
- 4.Clients check if certificate's serial number is on CRL
- 5.If on CRL → Certificate invalid
CRL Limitations:
- •Can be large (many revoked certificates)
- •Requires periodic download
- •Gap between revocation and CRL update
- •Clients may cache old CRLs
Online Certificate Status Protocol (OCSP)
OCSP provides real-time certificate status checking.
How OCSP Works:
- 1.Client sends certificate serial number to OCSP responder
- 2.OCSP responder checks current status
- 3.Responder returns: Good, Revoked, or Unknown
- 4.Real-time, on-demand verification
OCSP Advantages over CRL:
- •Real-time status (no waiting for CRL update)
- •Smaller response (single certificate vs. entire list)
- •Less bandwidth required
OCSP Stapling:
- •Server pre-fetches OCSP response
- •Server sends response with certificate
- •Client doesn't need to contact OCSP server
- •Improves performance and privacy
CRL vs. OCSP Comparison
| Aspect | CRL | OCSP |
|---|---|---|
| Timing | Periodic (delayed) | Real-time |
| Size | Large (all revoked certs) | Small (single response) |
| Bandwidth | Higher | Lower |
| Privacy | Better (no per-cert queries) | CA sees queries (without stapling) |
| Availability | Works offline (cached) | Requires responder access |
Wildcard Certificates
A wildcard certificate covers a domain and all its subdomains at one level.
Wildcard Format:
- •`*.example.com`
What It Covers:
- •www.example.com ✓
- •mail.example.com ✓
- •api.example.com ✓
What It Doesn't Cover:
- •example.com (base domain) ✗
- •sub.www.example.com (nested subdomain) ✗
Wildcard Advantages:
- •One certificate for multiple subdomains
- •Easier management
- •Cost-effective
Wildcard Risks:
- •Compromise affects ALL subdomains
- •Private key shared across servers
- •Some compliance requirements prohibit wildcards
Subject Alternative Name (SAN) Certificates
SAN certificates list multiple specific names in a single certificate.
SAN Use Cases:
- •Multiple domains: example.com, example.org, example.net
- •Domain + subdomains: example.com, www.example.com, mail.example.com
- •Internal + external names: server1.internal, server1.example.com
SAN vs. Wildcard:
- •Wildcard: Any subdomain of one domain
- •SAN: Specific listed names (can be completely different domains)
Certificate Types by Validation Level
| Type | Validation | Time | Use Case |
|---|---|---|---|
| Domain Validated (DV) | Domain control only | Minutes | Personal sites, testing |
| Organization Validated (OV) | Organization identity verified | Days | Business websites |
| Extended Validation (EV) | Thorough organization verification | Weeks | Banking, e-commerce |
Certificate Lifecycle Management
Monitoring:
- •Track all certificates in inventory
- •Alert before expiration (30, 60, 90 days)
- •Automated scanning for certificate discovery
Renewal:
- •Generate new CSR (or reuse if key is still secure)
- •Submit to CA before expiration
- •Deploy new certificate
- •Verify installation
Automation:
- •ACME protocol (used by Let's Encrypt)
- •Certificate management platforms
- •Automated renewal scripts
- •Integration with configuration management
How CompTIA Tests This
Example Analysis
Scenario: A company's website certificate expires in 15 days. The security team discovers the private key may have been exposed in a server backup that was accidentally made public. What actions should be taken?
Immediate Action: Revoke the Certificate • Private key exposure requires immediate revocation • Cannot wait for natural expiration • Exposed key means attackers could impersonate the site
Generate New Key Pair and CSR: • Create entirely new private key • Generate new CSR with new public key • Do NOT reuse the compromised key
Request New Certificate: • Submit new CSR to CA • Request expedited issuance if possible • Deploy new certificate immediately
Verify Revocation: • Confirm old certificate appears in CRL • Or verify OCSP returns "Revoked" status • Monitor for any unauthorized certificate use
Key insight: Don't just renew early—the compromised certificate must be REVOKED. Renewal alone doesn't invalidate the old certificate until it expires, leaving a window for attack.
Key Terms to Know
Common Mistakes to Avoid
Exam Tips
Memory Trick
- •CSR Process: "GCSS"
- •Generate key pair locally
- •Create CSR with public key
- •Send CSR to CA
- •Secure private key (never leaves)
- •CRL vs OCSP:
- •CRL = Cached Revocation List (download list, check locally)
- •OCSP = On-demand Certificate Status Protocol (ask server now)
- •Wildcard Memory:
- •`*.example.com` = "Star covers one level"
- •✓ anything.example.com
- •✗ example.com (no star)
- •✗ deeper.level.example.com (two levels)
- •Validation Levels:
- •DV = Domain only (quick, basic)
- •OV = Organization checked (moderate)
- •EV = Extensive verification (thorough)
Test Your Knowledge
Q1.During CSR generation, which component is sent to the Certificate Authority?
Q2.What is the PRIMARY advantage of OCSP over CRL for certificate revocation checking?
Q3.A wildcard certificate for *.company.com will secure which of the following?
Want more practice with instant AI feedback?
Practice with AIContinue Learning
Ready to test your knowledge?
Practice questions on certificate management and other Objective 1.4 concepts.