Google Chrome's 90-Day Default Is Gone: Navigating the New Browser Certificate Policies

The Browser Landscape Has Shifted

For years, the certificate lifetime debate played out between Certificate Authorities and the CA/Browser Forum. Browsers had opinions, but enforcement was mostly theoretical. That era is over.

In 2026, all three major browser vendors — Google, Apple, and Mozilla — have committed to enforcing shorter certificate lifetimes through their root store policies. But they're doing it on different timelines, with different enforcement mechanisms, and with different consequences for certificates that exceed the limits.

If you're managing certificates for an enterprise, understanding these differences isn't optional. A certificate that works perfectly in Chrome might trigger a warning in Safari or fail validation entirely in Firefox.

What Each Browser Is Doing

Google Chrome: Aligning with SC-081

Google initially proposed a unilateral move to 90-day maximum certificate lifetimes back in 2023. That proposal was controversial — it would have forced the industry to move faster than many organizations were prepared for.

Instead, Google pivoted to supporting the CA/Browser Forum's SC-081 ballot, which establishes a phased reduction:

┌──────────────────────────────────────────────────────────────┐
│              SC-081 Certificate Lifetime Timeline             │
├──────────────────┬───────────────────────────────────────────┤
│ Effective Date   │ Maximum Lifetime                          │
├──────────────────┼───────────────────────────────────────────┤
│ March 15, 2026   │ 200 days (with 200-day DCV reuse)         │
├──────────────────┼───────────────────────────────────────────┤
│ March 15, 2027   │ 100 days (with 100-day DCV reuse)         │
├──────────────────┼───────────────────────────────────────────┤
│ March 15, 2029   │ 47 days (with 10-day DCV reuse)           │
└──────────────────┴───────────────────────────────────────────┘

Chrome's root store policy now mirrors these dates. Certificates issued after each effective date must comply with the corresponding maximum lifetime, or Chrome will reject them during TLS handshake validation.

Chrome's enforcement mechanism: Hard failure. If a certificate exceeds the maximum lifetime for its issuance date, Chrome will display a full-page NET::ERR_CERT_VALIDITY_TOO_LONG error. No interstitial, no "proceed anyway" — a hard block identical to an expired certificate.

Apple Safari: Leading with 45 Days

Apple has consistently pushed for the shortest certificate lifetimes. Their root store policy already requires certificates to comply with SC-081 timelines, but Apple has signaled they may enforce a 45-day maximum — two days shorter than the SC-081 final target — as early as late 2028.

Apple's approach is informed by their experience with the App Store and code signing certificates, where short-lived credentials are the norm. Their position: if your renewal process can't handle 45 days, it can't handle 47 days either, so the two-day difference is irrelevant.

Safari's enforcement mechanism: Graduated. Safari currently shows a warning banner for certificates approaching the SC-081 limits. Starting with Safari 20 (expected fall 2026), certificates exceeding 200 days will trigger a full trust failure. Apple's approach gives users no option to bypass — the connection is blocked at the WebKit level.

Key difference from Chrome: Apple enforces at the operating system level, not just the browser. Any application using Apple's Security framework (URLSession, Network.framework) will reject certificates that violate the policy. This means:

• Native iOS and macOS apps are affected
• Electron apps on macOS are affected
• Any tool using /usr/bin/curl on macOS is affected

Mozilla Firefox: Pragmatic but Firm

Mozilla's approach balances security ideals with the practical reality that many organizations are still catching up. Firefox's root store policy aligns with SC-081, but Mozilla has added a grace period mechanism for the first two phases:

• 200-day phase (2026): 30-day grace period — certificates up to 230 days will show a warning, not a hard failure
• 100-day phase (2027): 15-day grace period — certificates up to 115 days will show a warning
• 47-day phase (2029): No grace period — hard enforcement

Firefox's enforcement mechanism: Configurable. Enterprise administrators can extend grace periods or disable lifetime checking entirely through Firefox's enterprise policies:

{
  "policies": {
    "Certificates": {
      "MaxLifetimeInDays": 200,
      "GracePeriodInDays": 30,
      "EnforceLifetime": true
    }
  }
}

This makes Firefox the most flexible browser for enterprises in transition — but relying on policy overrides is a temporary fix, not a strategy.

Browser Policy Comparison

What "Not Trusted" Actually Means

The phrase "certificate not trusted" means different things depending on the browser and the failure mode:

Hard Block (Chrome, Safari post-2026)

• Connection is terminated at the TLS layer
• No page content is loaded
• No user override is possible
• HSTS-preloaded domains get the same treatment
• API calls from JavaScript fail with network errors
• Service workers cannot intercept the failure

Warning Interstitial (Firefox grace period)

• A warning page is displayed
• Users can click "Accept the Risk and Continue"
• The decision is remembered for the session
• API calls from JavaScript still fail unless the user has already accepted
• Automated tools and headless browsers cannot bypass without configuration

The Real Impact

For most enterprises, the critical distinction is:

1. Customer-facing sites: Any trust failure — hard block or warning — drives users away. A Firefox warning interstitial has essentially the same business impact as a Chrome hard block.

2. Internal applications: Firefox's enterprise policies provide a safety valve, but only if you control the browser. BYOD devices, contractor machines, and mobile browsers won't have your policies.

3. API endpoints: Machine-to-machine communication using browsers or browser-based HTTP clients will fail silently. A certificate that's "just" 5 days over the limit will break automated integrations.

Root Store Policies vs. CA/B Forum Baseline

It's important to understand that browser root store policies can be stricter than the CA/B Forum Baseline Requirements. The CA/B Forum sets the floor; browsers can set their own ceiling.

Current divergences:

Certificate Transparency

All three browsers now require Certificate Transparency (CT) logs, but with different SCT requirements:

• Chrome: Requires 2 SCTs from distinct logs
• Safari: Requires 2 SCTs, at least one from an Apple-approved log
• Firefox: Requires 2 SCTs (aligned with Chrome as of Firefox 130)

Key Size Requirements

• Chrome/Safari: RSA minimum 2048-bit, ECDSA P-256 or P-384
• Firefox: Same minimums, but additionally recommends ECDSA P-384 for new certificates and has signaled P-256 deprecation timelines

Revocation Checking

• Chrome: CRLSets (Google's curated subset of CRLs) — does NOT check OCSP by default
• Safari: OCSP stapling preferred, falls back to OCSP responder
• Firefox: CRLite (Mozilla's compressed CRL database) + OCSP stapling

This means a certificate that's revoked might show as revoked in Safari (via OCSP) but not in Chrome (if it's not in CRLSets) — at least until CRLSets are updated.

What Enterprises Need to Do Now

1. Audit Your Current Certificate Lifetimes

Before you can plan, you need to know where you stand:

audit_checklist:
  inventory:
    - List all certificates with remaining lifetime > 200 days
    - Identify certificates issued after March 15, 2026 with lifetime > 200 days
    - Flag wildcard certificates (higher blast radius if renewal fails)

  categorize_by_risk:
    - customer_facing: "Must comply immediately — any trust failure loses revenue"
    - internal_apps: "Firefox policies buy time, but plan for full compliance"
    - api_endpoints: "Silent failures are the most dangerous — prioritize these"
    - iot_devices: "May not update browsers — verify embedded TLS libraries"

2. Test Across All Three Browsers

Don't assume that passing Chrome validation means you're safe everywhere:

• Test with Safari on macOS and iOS — remember Apple's OS-level enforcement
• Test with Firefox without enterprise policies to see what end users see
• Test with curl on macOS (it uses Apple's Security framework)
• Test mobile browsers — especially Samsung Internet and Edge, which have their own quirks

3. Automate Certificate Renewal

The math is unforgiving:

At 200-day certificates (2026):
  → You need to renew every ~6.5 months
  → Manageable manually for small environments

At 100-day certificates (2027):
  → You need to renew every ~3 months
  → Manual renewal becomes a full-time job at 100+ certificates

At 47-day certificates (2029):
  → You need to renew every ~30 days (accounting for renewal window)
  → Manual renewal is impossible at any scale

4. Plan for Apple's 45-Day Target

If Apple moves to 45-day enforcement before the SC-081 47-day deadline:

• Certificates valid for 46-47 days will work in Chrome and Firefox but fail in Safari
• Any automation built for "exactly 47 days" will break on Apple platforms
• The safest approach: target 45-day certificates now, regardless of which browser you're optimizing for

5. Update Your Monitoring

Your certificate monitoring needs to account for browser-specific policies:

• Alert when certificates are issued with lifetimes exceeding current browser limits
• Monitor for CT log inclusion (all browsers now require it)
• Track OCSP stapling status (critical for Safari validation)
• Verify revocation coverage in CRLSets and CRLite

How TigerTrust Keeps You Ahead of Browser Policies

TigerTrust's certificate lifecycle management platform is designed for exactly this kind of fragmented policy landscape:

• Policy engine: Configure certificate lifetime limits that are stricter than any individual browser requirement — issue 45-day certificates by default and satisfy all browsers simultaneously
• Cross-browser validation: Pre-issuance checks verify that certificates will pass validation in Chrome, Safari, and Firefox, including CT log requirements and key size policies
• Automated renewal: Certificates are renewed well before expiry, with configurable renewal windows that account for the shortest browser-enforced lifetime
• Discovery and audit: Identify every certificate in your infrastructure that exceeds current browser lifetime limits, with remediation priority based on exposure (customer-facing vs. internal)
• Real-time compliance dashboard: See at a glance which certificates comply with each browser's current and upcoming policies

Browser vendors are converging on shorter certificate lifetimes. The only question is whether your infrastructure converges with them. Start with TigerTrust at tigertrust.io.