CA/Browser Forum Baseline Requirements

The CA/Browser Forum Baseline Requirements (BRs) are a set of minimum standards that all publicly-trusted Certificate Authorities must follow when issuing TLS/SSL certificates. They define: how domain ownership is validated, what key sizes are acceptable, how long certificates can be valid, when certificates must be revoked, and what CAs must audit against. The BRs are enforced by browser root programs — if a CA violates them, browsers can restrict or remove that CA from their trust stores, effectively killing the CA’s business.

Why it matters

• Defines the rules of public trust — any CA in your browser’s trust store must comply with BRs. This is what prevents CAs from issuing certificates without proper validation.
• Drives industry changes — maximum validity reduction (from 5 years to 398 days), CT logging requirements, and deprecation of SHA-1 all came through BR ballots. The 90-day proposal is next.
• Enforcement has teeth — Symantec was distrusted by Chrome (2018) for BR violations. WoSign/StartCom were removed from Mozilla. DigiNotar collapsed. BR violations have real consequences.
• Affects your certificate strategy — BR changes (shorter validity, new validation methods, algorithm requirements) directly impact how you procure and manage certificates. Staying ahead of BR changes prevents disruption.
• Audit framework — CAs are audited annually against BRs (WebTrust for CAs or ETSI EN 319 411). The audit report is public and reviewed by browser root programs.

How it works

Key requirements (current BRs):

1. Maximum validity: 398 days for end-entity TLS certificates
2. Minimum key size: RSA 2048-bit, ECDSA P-256 or P-384
3. Signature algorithm: SHA-256 minimum (SHA-1 prohibited since 2016)
4. Domain validation: must use approved methods (HTTP-01, DNS-01, email to admin contacts, etc.)
5. Certificate Transparency: all certificates must be logged to CT logs before issuance
6. Revocation: CA must revoke within 24 hours of confirmed mis-issuance, 5 days for key compromise
7. CAA checking: CA must check DNS CAA records before issuance and honor them
8. Wildcard restrictions: wildcards only at the leftmost label, validation required for base domain
9. Internal names prohibited: certificates for .local, .internal, RFC 1918 IPs, or non-FQDN names are not allowed
10. Subscriber agreement: certificate holder must agree to terms including key protection and revocation obligations

Governance:

• CA/Browser Forum members: CAs (DigiCert, Let’s Encrypt, Sectigo, etc.) and browsers (Google, Mozilla, Apple, Microsoft)
• Changes via ballot: proposed, discussed, voted (2/3 CA majority + 2/3 browser majority required)
• Browser root programs can impose additional requirements beyond BRs

In real systems

CAA DNS records (BR requirement since 2017):

; Only Let's Encrypt and DigiCert can issue for this domain
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

; CAs MUST check CAA before issuance (BR §3.2.2.8)
; If CAA doesn't authorize the CA, issuance is prohibited

Certificate validity check:

# Check if a certificate exceeds BR maximum validity (398 days)
openssl x509 -in cert.pem -noout -startdate -enddate
# notBefore=Jan 1 00:00:00 2026 GMT
# notAfter=Feb 3 23:59:59 2027 GMT
# Duration: 399 days — VIOLATION (exceeds 398-day maximum)

BR-mandated revocation timelines:

Mis-issuance confirmed:     Revoke within 24 hours
Key compromise reported:    Revoke within 24 hours
Subscriber requests:        Revoke within 24 hours
CA compromise:              Revoke within 24 hours
Domain validation expired:  Revoke within 5 days
Certificate not compliant:  Revoke within 5 days

Incident reporting (BR §4.9.5):

When a CA discovers a BR violation in their own issuance:
1. Investigate scope (how many certificates affected)
2. Report to browser root programs (Bugzilla for Mozilla, public incident report)
3. Revoke affected certificates per timeline
4. Publish root cause analysis
5. Implement preventive measures
6. All reports are PUBLIC — the community reviews them

Where it breaks

CA issues certificate without proper validation — a CA’s automated system has a bug that skips domain validation for certain request patterns. Certificates are issued for domains the subscriber doesn’t control. Once discovered (via CT log monitoring or community report), the CA must revoke all affected certificates within 24 hours, file a public incident report, and face potential trust store action. This has happened to multiple CAs (Let’s Encrypt TLS-ALPN-01 bug 2022, various smaller CAs).

Validity period exceeds maximum — a CA’s system issues a certificate valid for 400 days (2 days over the 398-day BR limit). This is a BR violation even though the security impact is minimal. The CA must revoke the certificate and report the incident. Automated issuance systems must enforce validity limits with no tolerance — “close enough” doesn’t exist in BR compliance.

Internal name in public certificate — a subscriber requests a certificate for server.internal or 10.0.0.1 (RFC 1918 address) from a public CA. BRs prohibit this since 2015. The CA’s validation system should reject it, but if it slips through, the certificate must be revoked. Organizations needing certificates for internal names must use a private CA.

Operational insight

The CA/Browser Forum is where the future of your certificate management is decided — often 1-2 years before changes take effect. The 398-day maximum validity was announced in 2020 with a September 2020 enforcement date. The 90-day proposal has been discussed since 2023. Organizations that track BR ballot discussions can prepare for changes before they’re enforced. Subscribe to the CA/Browser Forum public mailing list and monitor ballot proposals. When a ballot passes, you typically have 6-12 months before enforcement. Use that time to adjust automation, update procurement processes, and communicate changes to teams that manage certificates.

Related topics

• What is a Certificate Authority
• Certificate Validity and 90-Day Proposals
• What is Certificate Transparency
• Certificate Policy and Practice Statement
• What is X.509