Apple’s 45-Day Certificate Policy: What It Means for Enterprise Teams

---

On October 9, 2024, Apple submitted a ballot proposal to the CA/Browser Forum that would reduce the maximum TLS certificate lifespan to 45 days by 2027. This isn’t a suggestion. Apple controls the Safari and iOS trust stores. When Apple decides a certificate policy, every public-facing service accessed by iPhone, iPad, or Mac users must comply — or break.

For enterprise teams running manual renewal processes, quarterly review cycles, or spreadsheet-based tracking, this represents a fundamental operational shift. Not a gradual one. A cliff.

This post breaks down exactly what Apple proposed, how it differs from Google’s parallel effort, what breaks in your current operations, and how to prepare before the deadline arrives.

---

Apple SC-081: Renewal Multiplier by Phase

Per-certificate annual renewals as maximum lifespan decreases

Manual feasible

1-2 renewals/year per cert

Automation required

4-8 renewals/year per cert

What Apple Actually Proposed: CA/Browser Forum Ballot SC-081

Apple’s proposal, tracked as Ballot SC-081 in the CA/Browser Forum, defines a phased reduction in maximum certificate validity periods:

Phase	Effective Date	Maximum Certificate Lifespan	Maximum DCV Reuse
Current	Today	398 days	398 days
Phase 1	March 15, 2026	200 days	200 days
Phase 2	March 15, 2027	100 days	100 days
Phase 3	March 15, 2028	45 days	10 days

The ballot also reduces Domain Control Validation (DCV) reuse periods — the window during which a CA can re-issue a certificate without re-validating domain ownership. At 45-day cert lifespans with 10-day DCV reuse, domain validation must happen almost continuously.

Apple’s rationale centers on three arguments:

1. Shorter compromise windows — A stolen private key is useful for 45 days maximum, not 398 days.
2. Faster algorithm migration — When the industry needs to deprecate an algorithm (as happened with SHA-1), shorter lifespans mean the ecosystem rotates faster without requiring mass revocations.
3. Revocation doesn’t work — CRL and OCSP checking is unreliable. Browsers don’t hard-fail on revocation check failures. Short lifespans make revocation less critical because certificates expire before revocation infrastructure needs to act.

This ballot passed the CA/Browser Forum Server Certificate Working Group in a vote concluded on April 11, 2025. It is now an official baseline requirement.

---

Apple’s 45-Day vs. Google’s 90-Day: Understanding Both Timelines

Google has been pushing for shorter certificate lifespans independently. Their “Moving Forward, Together” initiative proposed 90-day maximum validity. Here’s how the two compare:

Dimension	Apple (SC-081)	Google (Chrome Root Program)
Target Maximum Lifespan	45 days	90 days
Final Deadline	March 15, 2028	Not formally balloted yet
Enforcement Mechanism	Safari/iOS trust store	Chrome trust store
DCV Reuse Period	10 days	Not specified
Current Status	Ballot passed (April 2025)	Policy intent announced
Phased Rollout	Yes (200 → 100 → 45 days)	Single step proposed

The critical difference: Apple’s proposal is now ratified. Google’s remains directional guidance. But both converge on the same conclusion — the era of annual certificate renewals is ending.

For enterprise planning purposes, you should architect for 45 days. If you can handle 45, you can handle 90. The reverse isn’t true.

---

The 8x Multiplier: Impact on Renewal Volume

The math is straightforward but the operational impact is severe.

Current state (398-day certificates):

• 1 renewal per certificate per year
• 500 certificates = 500 renewals/year = ~42 renewals/month = ~10 renewals/week

At 45-day lifespans:

• 8.1 renewals per certificate per year (365 ÷ 45)
• 500 certificates = 4,055 renewals/year = ~338 renewals/month = ~78 renewals/week

Certificate Count	Annual Renewals (398-day)	Annual Renewals (45-day)	Weekly Volume (45-day)
100	100	811	16
500	500	4,055	78
1,000	1,000	8,111	156
5,000	5,000	40,555	780
10,000	10,000	81,111	1,560

At 78 renewals per week for a 500-certificate environment, manual processing is mathematically impossible for a team that also has other responsibilities. Each renewal involves validation, issuance, deployment, and verification — even in a semi-automated flow, that’s 15-30 minutes per certificate. At 78/week, that’s 19-39 hours of certificate work every week. For one team.

---

What Breaks at 45-Day Lifespans

Every process designed around annual or bi-annual renewal cadences fails. Here’s the specific breakdown:

Current Process	Why It Breaks at 45 Days	Failure Mode
Spreadsheet tracking	8x more entries, daily updates needed	Tracking falls behind within 2 weeks
Calendar reminders	Overlap constantly; alert fatigue sets in	Renewals ignored or missed
Quarterly review meetings	Certificates expire between meetings	Outages between review cycles
Manual CSR generation	78 CSRs/week for 500 certs	Unsustainable manual workload
Email-based approval workflows	Approval queue becomes bottleneck	Certificates expire waiting for approval
Change advisory board (CAB) tickets	78 tickets/week overwhelms CAB process	CAB becomes blocker, not governance
Annual budget planning for cert purchases	8x cost increase; budget models break	Budget exhausted by Q2
Vendor-portal manual renewals	78 portal logins/week	Staff time consumed entirely
Static certificate pinning	Pins expire before app updates deploy	Mobile apps break in production
Hardcoded certificates in containers	Container images expire within 45 days	Services fail after redeployment

The Compounding Problem

These don’t fail independently. They cascade. A missed renewal triggers an outage. The outage requires emergency response. Emergency response pulls staff from processing the next batch of renewals. More renewals are missed. More outages follow.

At annual cadence, you can recover from a miss. At 45-day cadence, falling behind by one week means you never catch up without automation.

---

Safari and iOS Trust Store: What Enterprises Must Understand

Apple doesn’t negotiate trust store policies with individual enterprises. Their enforcement model is binary:

• If your certificate exceeds the maximum validity at issuance time, Safari will reject it with a trust error.
• If your certificate was issued before the policy date with a longer validity, it remains trusted until it expires (grandfather clause applies to existing certificates, not new issuances).
• iOS apps using URLSession and WKWebView inherit Safari’s trust decisions. Corporate MDM profiles cannot override root program policies for publicly-trusted certificates.

What This Means for Enterprise Web Properties

Every public-facing service accessed via Safari or iOS — customer portals, partner APIs, B2B integrations, marketing sites, CDN endpoints — must have certificates renewed within the 45-day window.

What This Means for Internal Services

Apple’s policy only directly applies to publicly-trusted certificates. Internal certificates issued by private CAs (AD CS, HashiCorp Vault, step-ca) are not bound by CA/Browser Forum rules.

However, there are indirect effects:

1. Auditor expectations shift — When public certificates are managed at 45-day cycles, auditors begin questioning why internal certificates have 2-year lifespans. “If the industry standard is 45 days, justify your 730-day internal policy.”

2. Tool consolidation pressure — If you automate public cert renewals, the same tooling can (and should) manage internal certificates. The operational argument for long-lived internal certs weakens.

3. Compliance frameworks update — NIST, PCI DSS, and SOC 2 auditors follow industry momentum. Expect shorter internal certificate lifespans in future framework revisions.

---

Automation Requirements: What You Need in Place

Manual processes cannot survive 45-day lifespans. Automation isn’t optional — it’s the only viable operating model. Here’s what the automation stack looks like:

ACME Protocol (RFC 8555)

The Automatic Certificate Management Environment protocol is the foundation. Originally developed for Let’s Encrypt, ACME is now supported by DigiCert, Sectigo, Entrust, and other commercial CAs.

ACME handles:

• Domain validation (HTTP-01, DNS-01, TLS-ALPN-01 challenges)
• Certificate issuance
• Renewal triggering
• Key rollover

cert-manager (Kubernetes Environments)

For container orchestration platforms, cert-manager is the standard:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: webapp-tls
  namespace: production
spec:
  secretName: webapp-tls-secret
  duration: 720h        # 30 days
  renewBefore: 360h     # Renew 15 days before expiry
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - app.example.com
    - api.example.com

With renewBefore set to half the certificate lifetime, cert-manager handles renewal automatically with sufficient buffer for transient failures.

Certbot Auto-Renewal Configuration

For traditional Linux servers, certbot with systemd timers provides reliable automation:

# /etc/systemd/system/certbot-renewal.timer
[Unit]
Description=Certbot renewal timer

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/certbot-renewal.service
[Unit]
Description=Certbot renewal service
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --deploy-hook "/usr/local/bin/reload-services.sh"
ExecStartPost=/usr/local/bin/verify-certs.sh

[Install]
WantedBy=multi-user.target

# /usr/local/bin/reload-services.sh
#!/bin/bash
systemctl reload nginx
systemctl reload haproxy
# Notify monitoring system
curl -s -X POST https://monitoring.internal/api/events \
  -H "Content-Type: application/json" \
  -d '{"event":"cert_renewed","host":"'"$(hostname)"'","timestamp":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}'

# /usr/local/bin/verify-certs.sh
#!/bin/bash
# Verify renewed certificates are valid and deployed
for domain in $(certbot certificates 2>/dev/null | grep "Domains:" | sed 's/.*Domains: //'); do
  expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null | \
    openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  if [ -z "$expiry" ]; then
    echo "ALERT: Certificate verification failed for $domain" | \
      mail -s "Cert Verification Failed" security-team@example.com
  fi
done

CLM Platforms

For environments with 500+ certificates across multiple CAs, a Certificate Lifecycle Management platform provides:

• Centralized discovery across all certificate sources
• Policy-based automation rules
• Multi-CA support (ACME + proprietary APIs)
• Deployment orchestration (push certificates to load balancers, CDNs, appliances)
• Audit trail for compliance

Platforms in this category: Venafi TLS Protect, Keyfactor Command, Sectigo Certificate Manager, DigiCert Trust Lifecycle Manager, AppViewX CERT+.

---

5-Phase Transition Plan

The 2028 deadline feels distant. It isn’t. Automation projects in enterprise environments take 12-18 months from approval to full production deployment. Start now.

Phase 1: Inventory and Assessment (Months 1-2)

Objective: Know what you have before you change anything.

Activity	Output
Scan all public DNS records for TLS certificates	Complete external certificate inventory
Query all CAs for issued certificates (CT logs, CA portals)	Certificates by issuer and validity
Map certificates to service owners	Ownership matrix
Identify certificates with manual renewal processes	Automation candidates list
Document current renewal workflows	Process map for gap analysis

Key deliverable: A spreadsheet (yes, for now) with every public certificate, its owner, its current validity period, and its renewal method (manual/automated/unknown).

Phase 2: Automation Infrastructure (Months 3-5)

Objective: Build the platform that will handle 8x renewal volume.

• Deploy ACME infrastructure (or select and procure CLM platform)
• Configure DNS-01 challenge automation for wildcard certificates
• Establish HTTP-01 challenge infrastructure for standard certificates
• Integrate with existing load balancers and reverse proxies
• Build deployment pipelines for certificate push to endpoints
• Implement monitoring and alerting for renewal failures

Phase 3: Pilot Migration (Months 6-8)

Objective: Prove automation works on low-risk certificates before trusting it with production.

• Migrate development and staging environment certificates first
• Move non-critical public services to automated renewal
• Validate renewal at 100-day lifespan (Phase 1 compliance)
• Document and resolve integration issues
• Train operations team on new workflows and escalation paths

Phase 4: Production Migration (Months 9-14)

Objective: Move all production certificates to automated renewal.

• Migrate production web properties in priority order (highest traffic first)
• Convert API endpoint certificates to automated issuance
• Migrate CDN and edge certificates
• Address legacy systems that cannot support ACME (appliances, embedded devices)
• Implement exception process for certificates that cannot be automated

Phase 5: Optimization and 45-Day Readiness (Months 15-18)

Objective: Reduce certificate lifespans to 45 days and confirm the system handles it without intervention.

• Reduce certificate validity from 100 days to 45 days
• Stress-test renewal infrastructure at full volume
• Implement redundancy for renewal infrastructure (what happens if your ACME server is down for 48 hours?)
• Run chaos engineering exercises (kill a renewal, does alerting catch it?)
• Document operational runbooks for failure scenarios
• Achieve steady-state: zero manual certificate renewals for public certificates

---

Comparison Table: Current State vs. Required State

Dimension	Current State (398-day)	Required State (45-day)
Renewal frequency	Annual	Every 45 days (8x/year)
Process type	Manual or semi-manual	Fully automated
Failure tolerance	Days to recover	Hours to recover
Monitoring cadence	Weekly or monthly checks	Continuous (real-time)
Team skillset	Certificate admin	Automation engineering
Budget model	Per-certificate annual cost	Platform + operational cost
Change management	CAB approval per renewal	Policy-based auto-approval
Validation method	Portal-based manual DCV	Automated DNS-01/HTTP-01
Deployment method	Manual copy to servers	Orchestrated push/pull
Rollback capability	Restore from backup	Automated re-issuance
Documentation	Tribal knowledge	Codified in automation
Vendor relationship	Transactional (buy certs)	Platform partnership

---

Cost Implications

The financial impact extends beyond certificate purchase costs:

Cost Category	Current (398-day, 500 certs)	Projected (45-day, 500 certs)
Certificate purchases (DV)	$0-$25,000/year	$0-$25,000/year (volume unchanged with automation)
Certificate purchases (OV/EV)	$50,000-$150,000/year	Same (OV/EV may retain longer validity or shift to DV)
Staff time (manual renewal)	500 hours/year	0 hours (automated)
CLM platform license	$0	$30,000-$150,000/year
Automation engineering (one-time)	$0	$80,000-$200,000 (project cost)
Outage cost (2-3/year avg)	$50,000-$500,000/year	Near zero (automated recovery)
Net annual impact	$100K-$675K total cost	$30K-$175K steady-state

The ROI case is clear for organizations experiencing certificate outages. The automation investment pays for itself within the first year by eliminating outage costs and reclaiming staff time.

---

Legacy System Challenges

Not every system supports ACME or automated certificate deployment. Enterprises typically have 10-20% of their certificate estate on systems that resist automation:

System Type	Challenge	Mitigation Strategy
Network appliances (F5, Citrix ADC)	Vendor-specific APIs, no ACME support	Use CLM platform with vendor integrations
Legacy Java applications	Certificates in JKS keystores, requires restart	Deploy sidecar that updates keystore + triggers graceful restart
Mainframe systems (z/OS)	Proprietary certificate management (RACF)	API bridge between ACME and RACF
Embedded devices (IoT gateways)	Cannot run agents, limited update mechanisms	EST protocol (RFC 7030) for lightweight enrollment
Third-party SaaS integrations	You upload certificates to their portal	API automation if available; manual exception process if not
Windows IIS with AD CS	Auto-enrollment covers internal; public certs need separate automation	Hybrid: AD CS for internal + ACME for public
Load balancers (hardware)	Certificate deployment requires vendor CLI/API	Orchestration layer that pushes via vendor API

The Exception Registry

For systems that genuinely cannot be automated, maintain an exception registry:

• System name and purpose
• Why automation is not possible (with evidence)
• Manual renewal procedure (documented, not tribal knowledge)
• Named owner responsible for manual renewal
• Monitoring alert set to 30 days before expiry (minimum)
• Quarterly review to reassess whether automation is now possible

The goal is zero exceptions. The reality is you’ll have 5-15% exceptions initially, reducing to under 2% over 18 months as legacy systems are upgraded or replaced.

---

Monitoring and Alerting Architecture

Automation without monitoring is automation without safety nets. At 45-day lifespans, your monitoring must catch failures within hours, not days.

Required Alert Conditions

Alert	Trigger	Severity	Response SLA
Renewal failed	ACME client returns error on renewal attempt	Critical	4 hours
Certificate expiring in < 14 days	No successful renewal detected	High	24 hours
Certificate expiring in < 7 days	Imminent outage risk	Critical	2 hours
New certificate not deployed	Issued but not verified on endpoint	High	4 hours
Certificate chain incomplete	Intermediate missing from deployment	Medium	8 hours
CT log certificate not in inventory	Unknown certificate for your domain	Medium	24 hours

Verification After Renewal

Automation must verify, not just execute:

# Post-renewal verification script
#!/bin/bash
DOMAIN=$1
EXPECTED_SERIAL=$2

# Verify the new certificate is serving
ACTUAL_SERIAL=$(echo | openssl s_client -servername "$DOMAIN" \
  -connect "$DOMAIN:443" 2>/dev/null | \
  openssl x509 -noout -serial 2>/dev/null | cut -d= -f2)

if [ "$ACTUAL_SERIAL" != "$EXPECTED_SERIAL" ]; then
  echo "CRITICAL: $DOMAIN serving old certificate"
  echo "Expected: $EXPECTED_SERIAL"
  echo "Actual:   $ACTUAL_SERIAL"
  exit 1
fi

# Verify expiry is in the future (beyond 30 days)
EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" \
  -connect "$DOMAIN:443" 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
THRESHOLD_EPOCH=$(date -d "+30 days" +%s)

if [ "$EXPIRY_EPOCH" -lt "$THRESHOLD_EPOCH" ]; then
  echo "WARNING: $DOMAIN certificate expires within 30 days"
  exit 2
fi

echo "OK: $DOMAIN verified with correct certificate"
exit 0

---

What to Do This Quarter

Regardless of where you are in your automation journey, these actions are relevant now:

1. Inventory your public certificates — Use Certificate Transparency logs (crt.sh) to find every certificate issued for your domains. Compare against your internal records. The gap represents your blind spot.

2. Identify your top 10 highest-risk certificates — The ones protecting revenue-generating services, customer-facing applications, and partner integrations. These get automated first.

3. Test ACME with one certificate — Pick a low-risk service. Set up certbot or cert-manager. Prove the workflow. This takes one afternoon and removes the “we’ve never done this” objection.

4. Talk to your CA — Ask about ACME support, API access, and volume pricing. If your current CA doesn’t support ACME, that’s a vendor evaluation trigger.

5. Brief leadership — This isn’t an infrastructure curiosity. It’s a compliance deadline. Frame it in terms of business risk: “After March 2028, our customer-facing services will display trust errors on every iPhone and Mac unless we automate certificate renewal.”

---

About QCecuring

QCecuring helps enterprise teams build the automation infrastructure required for short-lived certificate environments. We provide certificate lifecycle management assessment, automation architecture design, and implementation services — from initial inventory through production-ready 45-day renewal operations.

Our platform provides continuous certificate discovery, automated renewal orchestration, and compliance reporting designed for the operational reality of 45-day certificate lifespans.

Talk to us about 45-day readiness →

---

Tags: Apple, 45-Day Certificates, CA/Browser Forum, SC-081, Certificate Automation, ACME, certbot, cert-manager, CLM, Certificate Lifecycle Management, PKI, Safari, iOS, TLS, Short-Lived Certificates, Enterprise Security