Already know PKI? Here's the summary:
- Key protection - Subscriber warranties typically state no unauthorized access to private key has occurred, with ongoing protection obligations (CPS 9.6.3)
- Accuracy duty - Continuous obligation to monitor and report info changes within 24h
- Use restrictions - TLS only for DV; no CA operations; no prohibited uses (nuclear, weapons, etc.)
- Revocation trigger - Material violations are grounds for revocation under CA's CPS and Baseline Requirements (BR 4.9.1)
- Legal exposure - Subscriber indemnifies CA for damages from misrepresentation or misuse
The Agreement Nobody Reads
When you request a certificate from any public CA, you agree to their Subscriber Agreement (sometimes called Terms of Service or Certificate Services Agreement). This isn't just legal boilerplate - it's a binding contract with real obligations.
Many certificate requesters click through without reading. Then they're surprised when their certificate gets revoked for violating terms they didn't know existed.
What You're Actually Signing
Every major CA's subscriber agreement includes obligations derived from the CA/Browser Forum Baseline Requirements. While the exact wording varies, the core commitments are standardized across the industry.
These obligations apply to:
- • The person who requests the certificate (you)
- • The organization the certificate is issued to
- • Anyone who uses the private key
With certificate validity shrinking (soon to be 47 days per Apple's push), you'll be agreeing to these terms more frequently. Understanding your obligations isn't optional anymore - it's operational hygiene.
The Six Core Obligations
1Private Key Protection
You warrant that:
"No unauthorized person has ever had access to the Subscriber's Private Key"
This is past tense and absolute. You're not just promising to protect the key going forward - you're asserting that it has NEVER been compromised.
What this means in practice:
- • Generate keys on secure systems only
- • Never transmit private keys over unencrypted channels
- • Never share private keys via email, Slack, or tickets
- • Store keys in HSMs, secure key stores, or encrypted at rest
- • Limit access to keys on a need-to-know basis
- • Maintain audit logs of key access
The F5/load balancer trap: When you upload a certificate to an F5, Akamai, or CDN, you're extending "authorized access" to those systems. Make sure your organization has authorized that access - and that those systems meet your security standards.
2Information Accuracy
You warrant that:
"All information in the certificate request is accurate and true"
AND you have a:
"Continuous obligation to monitor the accuracy of submitted information"
This isn't a one-time thing. If your organization name changes, if you lose control of a domain, if any certificate information becomes inaccurate - you must notify your CA.
What triggers this obligation:
- • Company name change (merger, acquisition, rebrand)
- • Domain sold or transferred
- • Business address change (for OV/EV certificates)
- • Contact person leaves the organization
- • Organization ceases to exist
Timeline: Most subscriber agreements require notification within 24 hours of becoming aware of inaccurate information. This can trigger certificate revocation - not as punishment, but because the certificate no longer represents truth.
3Authorized and Legal Use Only
You warrant that:
"Certificate will be used exclusively for authorized and legal purposes"
- • You have permission from your organization
- • The domains are legitimately controlled by your org
- • You're authorized to bind your org to the agreement
- • No phishing or impersonation
- • No malware distribution
- • No fraud
- • Compliance with all applicable laws
The export control gotcha: Cryptographic software is considered "dual-use technology" under many countries' export regulations (for example, U.S. EAR controls on certain cryptographic implementations). If you're using certificates in systems that cross international boundaries, you may have export compliance obligations.
4No CA Operations
You warrant that:
"Subscriber will not use the certificate to sign other certificates"
In other words: you're not allowed to act as a Certificate Authority.
Why this exists: Your TLS certificate contains constraints (specifically, the Basic Constraints extension with CA:FALSE) that prevent it from issuing other certificates. But some older or misconfigured systems might not enforce these constraints. This warranty makes clear that even if you technically could, you're contractually prohibited.
What this doesn't restrict: Using the certificate for TLS as intended, using the private key for TLS session key derivation, and normal server authentication operations.
Learn about CA Hierarchy5Prompt Revocation Reporting
You warrant to:
"Promptly request revocation if any information changes or key is compromised"
"Promptly" means within 24 hours in most agreements, aligning with the CA's own revocation timeline obligations.
You must request revocation when:
- • Private key is compromised or suspected compromised
- • Information in the certificate is no longer accurate
- • You no longer control the domain(s)
- • The certificate was obtained using false information
- • You're no longer authorized to use the certificate
Pro tip: Know your CA's revocation process before you need it. During a 2am incident is not the time to figure out how to contact them.
6Indemnification
You agree to:
"Indemnify and hold harmless the CA from any damages arising from misrepresentation or misuse"
Translation: If your certificate is used for something bad, and the CA gets sued, you're paying the legal bills.
This is a high-level explanation; for actual legal interpretation, involve your legal team.
- • Damages from inaccurate cert info
- • Liability from certificate misuse
- • Costs of defending claims
- • Third-party claims from your cert
- • You're not liable for CA mistakes
- • CA mis-issuance is on them
- • CA revocation failures are theirs
DV vs OV vs EV - Different Obligations
The level of validation affects what you're warranting.
DVDomain Validation Certificates
Minimal obligations beyond the core six:
- • You control the domain (proven via DNS, HTTP, or email challenge)
- • Certificate used for server authentication only
You are NOT warranting: Organizational identity, physical address, or legal existence.
OVOrganization Validation Certificates
Additional obligations:
- • Organization legally exists
- • Organization name is accurate
- • Business address is accurate
- • Organization has authorized the certificate request
EVExtended Validation Certificates
Maximum obligations - all OV obligations, plus:
- • Specific individual is authorized to request certificates
- • Organization's operational existence confirmed
- • Physical address verified
- • Phone number verified
Note: The Baseline Requirements standardize EV identity verification steps across all CAs, which is why the accuracy burden and verification obligations are significantly higher for EV certificates.
The accuracy burden increases with validation level. EV certificate holders have the most to keep accurate - and the most to lose if information becomes stale.
Prohibited Uses
Every subscriber agreement explicitly prohibits certain uses. From a typical CPS (Section 1.4.2):
| Prohibited Use | Why |
|---|---|
| Control of hazardous equipment | Certificates aren't designed for safety-critical real-time control |
| Nuclear facilities | Fail-safe requirements exceed certificate capabilities |
| Aircraft navigation / air traffic control | Life-safety systems need different assurance |
| Weapons systems | Obvious reasons |
| DV certificates for identity assurance | DV only proves domain control, not identity |
| Any use inconsistent with applicable law | Catch-all for illegal activities |
This is worth emphasizing: DV certificates prove you control a domain. They do NOT prove:
- • Who you are
- • That you're a legitimate business
- • That you're who you claim to be
- • Anything about your identity
If you're using DV certificates in a context where users might assume identity validation (like a banking site or e-commerce), you may be violating your subscriber agreement.
What Happens When You Violate Obligations
Violation of subscriber obligations triggers consequences:
Immediate
- Certificate Revocation - CA can revoke immediately for material breaches
- Service Termination - CA can refuse future issuance
- No Refund - Most agreements specify no refund for revoked certs
Legal
- Indemnification Claims - CA can seek damages from you
- Third-Party Claims - Affected parties can sue directly
- Regulatory Action - Industry-specific penalties (finance, healthcare)
Reputational
- CT Logs - Certificate Transparency means revocation is public
- Incident Reports - Major incidents appear in CCADB
- Customer Trust - Certificate errors damage confidence
Real-World Violation Scenarios
Scenario 1The Shared Key
A developer emails a .pfx file with the private key to a colleague. Months later, the colleague's laptop is stolen.
Scenario 2The Forgotten Domain
Your company sells a subsidiary and transfers its domains, but forgets to revoke the wildcard certificate that covers those domains.
Scenario 3The Unauthorized Request
An IT contractor requests a certificate for a production domain without going through proper approval channels.
Scenario 4The Expired Company
A startup shuts down but their certificates remain active on archived/legacy systems.
How to Stay Compliant
For Individual Certificate Requesters
| Obligation | How to Comply |
|---|---|
| Key protection | Use secure generation, never share keys, use key management tools |
| Information accuracy | Verify all info before submission, update CA if anything changes |
| Authorized use | Get written approval before requesting production certificates |
| Legal use | Don't use certificates for anything sketchy |
| Prompt revocation | Know your CA's revocation process, report compromises within 24h |
For Organizations
Create a Certificate Policy that covers:
- 1Who can request certificates - Named individuals or roles with explicit authorization
- 2Key generation standards - HSM requirements, entropy sources, key sizes
- 3Key storage requirements - Where keys can and cannot be stored
- 4Change notification process - How to report when certificate info becomes inaccurate
- 5Revocation procedures - Who can request revocation and how
- 6Regular review - Periodic audit of certificate inventory and compliance
Reading Your Actual Agreement
Want to know exactly what you agreed to? Here's where to find subscriber agreements for major CAs:
| CA | Subscriber Agreement Location |
|---|---|
| DigiCert | digicert.com/legal-repository |
| Sectigo | sectigo.com/legal |
| Let's Encrypt | letsencrypt.org/repository |
| GlobalSign | globalsign.com/repository |
| GoDaddy | godaddy.com/legal/agreements |
What to Look For
- 1.Subscriber Obligations section - Usually Section 9.6.3 in the CPS
- 2.Revocation conditions - Section 4.9 typically
- 3.Warranties and representations - What you're asserting
- 4.Liability limitations - What the CA won't be responsible for
- 5.Indemnification - What you'll be responsible for
Pro tip: The Certificate Practice Statement (CPS) contains more detail than the subscriber agreement summary. Read both.
Frequently Asked Questions
Does everyone who touches the certificate need to understand these obligations?
The person who requests the certificate is binding the organization. But everyone who handles the private key should understand key protection obligations. Consider this part of security awareness training.
What if I inherited certificates from a predecessor who may have violated obligations?
You can't warrant past compliance you don't know about. If you discover a violation (like keys that were shared inappropriately), treat it as a suspected compromise and request revocation. Start fresh with clean key generation.
Do these obligations apply to free certificates like Let's Encrypt?
Yes. Let's Encrypt has a subscriber agreement just like commercial CAs. Free doesn't mean obligation-free.
What if my organization's name changed but the certificate still works fine?
For DV certificates, this typically doesn't matter (organization name isn't in the cert). For OV/EV, the certificate now contains inaccurate information and should technically be replaced. Most organizations handle this at renewal rather than immediate revocation.
Can I transfer a certificate to a new owner?
Generally no. Certificates are issued to a specific subscriber. If ownership of a domain transfers, the new owner should request their own certificate. The old certificate should be revoked.
What if I'm using a certificate for testing/development?
Same obligations apply, though the risk profile is different. Best practice: use separate certificates for dev/test and production, and treat private key protection seriously even in dev environments (they often get promoted to production).
Key Takeaways
- 1You made promises - The subscriber agreement is a binding contract, not just legal boilerplate
- 2Key protection is absolute - You warrant the key has NEVER been compromised, not just "recently"
- 3Accuracy is ongoing - You must monitor and report changes, not just be accurate at issuance
- 4Violations = revocation - Breaking obligations is grounds for immediate revocation
- 5Indemnification is real - If things go wrong due to your violations, you're on the hook
- 6Know before you need - Understand revocation procedures before an incident