Browser SSL Trust: How Google, Apple, Mozilla and Microsoft Differ

In March 2025, Apple published a proposal to reduce the maximum validity of TLS certificates to 45 days. The CA/B Forum had not yet voted on it. Apple announced it unilaterally, effective April 2025, before any industry consensus existed. The CA/B Forum ballot SC-081v3 followed in April 2025, formalizing a slightly different schedule (47 days by March 2029) after the fact.

This sequence matters. Apple did not ask permission. It set a policy that affected every website and every CA globally because Apple controls Safari and the iOS/macOS root store. Google deployed post-quantum cryptography hybrid key exchange in Chrome 116 in August 2023, years ahead of any CA/B Forum mandate, because Google controls Chrome and had already decided. Mozilla organized more than 500 security researchers to oppose the EU’s eIDAS 2.0 Article 45 provision that would have required browsers to trust government-designated CAs, because Mozilla decided EU digital sovereignty did not override browser security governance.

The CA/B Forum operates by multi-stakeholder consensus. Browser vendors are members. But browser vendors also have independent unilateral power over their own root stores, and they exercise it. Understanding each browser vendor’s distinct agenda for SSL and web trust is the prerequisite for understanding why certificate policy keeps changing in ways that feel arbitrary to developers and buyers. It is not arbitrary. It is the collision of four different visions for the future of internet security.

The Four Agendas at a Glance

Google: Automation, Measurement, and Control

Google’s SSL policy positions are coherent from a single principle: certificates should be short-lived, automated, and continuously monitored. Every major Google action in SSL policy advances this principle.

Google invented Certificate Transparency in 2013, shortly after the DigiNotar collapse. CT is a public audit log of every certificate issued by every CA. Before CT, CAs could issue certificates without any public record. After CT (mandatory since 2018), every certificate is logged within 24 hours and can be audited by anyone. Google deployed and operates multiple CT logs. Certificate Transparency is the most significant unilateral contribution by any browser vendor to CA accountability, and it was Google’s invention, driven by Google’s engineering team and deployed in Google Chrome.

The Chrome Root Store, established as an independent program in 2022, separated Chrome’s trust decisions from Windows’ trust store. Previously, Chrome on Windows inherited Microsoft’s certificate trust decisions. Now Google evaluates CAs independently. The Entrust distrust of 2024 was announced by Google first, with Chrome cutoff dates earlier than Apple’s and Mozilla’s. Google decided, informed the others, and the industry followed.

Google Trust Services, Google’s own CA, issues certificates for Google infrastructure and external customers. The dual role of CA operator and root store owner creates the governance tension described in the CA concentration article, but it also reflects Google’s vision: a large, trusted entity should be able to operate both roles transparently, with CT logs providing the external audit mechanism that makes the dual role safe. Google’s answer to ‘who watches the watchmen’ is: the CT logs watch everyone, including Google.

The 47-day validity trajectory is Google’s preferred direction. Shorter certificates force ACME automation. Automation means fewer expiry-related outages. Fewer outages means a faster, more reliable web. A faster, more reliable web serves more Google ads. The incentive alignment is transparent and consistent.

Google deployed X25519Kyber768 PQC hybrid key exchange in Chrome 116 in August 2023, more than a year before any CA/B Forum mandate for PQC. Google did not wait for consensus. It deployed, generated data from real-world usage, and shared the results. This is Google’s operating pattern in SSL policy: deploy first, measure, then advocate at the forum from a position of empirical evidence.

Apple: Device Identity and Hardware-Bound Trust

Apple’s approach to SSL and web trust is shaped by a fundamentally different model of identity than the domain-centric model that the rest of the CA ecosystem uses. Apple’s trust model centers on the Secure Enclave, a dedicated hardware security processor in every Apple device since 2013. The Secure Enclave generates and stores cryptographic keys that never leave the hardware. Apple’s internal certificate infrastructure for iCloud, Apple Pay, and Apple services uses this hardware-bound key model.

The certificate validity reduction Apple announced unilaterally in March 2025 is consistent with this model. Apple’s own internal services renew certificates constantly because they are automated and because Apple’s infrastructure was built for it. Extending the same short-validity requirement to the public CA ecosystem forces external operators toward Apple’s operational model: automation, frequent renewal, no reliance on long-lived certificates that sit unmonitored.

Apple’s conservative approach to third-party CA trust is also consistent with its hardware-centric model. Apple has been slower than Google and Mozilla to add new CAs to its trust store and has maintained stricter requirements for CA inclusion. The Apple Root Certificate Program has requirements that are in some areas stricter than the CA/B Forum Baseline Requirements. Apple’s reasoning: browser trust should be hard to earn and easy to lose, which concentrates issuance in CAs that have earned Apple’s confidence.

The iOS app distribution certificate system illustrates Apple’s full model. Every iOS app developer must have an Apple-issued certificate to distribute apps. Apple controls the issuance, the revocation, and the root. There is no third-party CA for iOS app distribution. This is the endpoint of Apple’s trust vision: not just shorter-lived domain certificates, but hardware-bound, Apple-controlled identity infrastructure for the most sensitive operations.

The tension between Apple’s unilateral validity announcement and the CA/B Forum’s multi-stakeholder process is worth naming explicitly. Apple did not circulate a draft ballot for comment before announcing 45-day validity. Apple announced, and the CA/B Forum scrambled to formalize a slightly different schedule (47 days vs 45 days, on a longer timeline) in the subsequent ballot. This pattern, where Apple sets policy unilaterally and the forum follows, is a structural feature of how Apple exercises its root store power. It is not unique to this event.

Mozilla: Privacy, Anti-Surveillance, and the Open Web

Mozilla’s SSL policy positions are the most ideologically explicit of the four browser vendors. Mozilla is a nonprofit. Its user base is self-selected toward users who care about privacy and open standards. Its corporate charter explicitly includes user privacy as a mission objective. These constraints make Mozilla’s SSL policy positions coherent in a way that is distinct from the commercial incentives that drive Google, Apple, and Microsoft.

Mozilla was a founding partner of Let’s Encrypt in 2015, alongside EFF, Cisco, Akamai, and the University of Michigan. The rationale was explicit: HTTPS should be universal and free, because a pay wall to encryption is a privacy problem. Let’s Encrypt has issued over a billion certificates and now holds approximately 54% of global certificate issuance. Mozilla’s early institutional support was essential to Let’s Encrypt achieving the scale that made universal HTTPS adoption economically feasible.

Mozilla’s CRLite implementation addresses a privacy problem in certificate revocation that the other browsers have handled differently. Standard revocation checking via OCSP requires the browser to send a request to the CA’s OCSP responder every time a user visits a site. This tells the CA which sites the user is visiting. CRLite downloads a compressed filter of all revoked certificates, so the browser can check revocation status locally without any network request to the CA. It eliminates the browsing surveillance that OCSP enables for CAs.

The eIDAS 2.0 Article 45 opposition was the most visible example of Mozilla’s anti-surveillance position in action. The draft Article 45 provision would have required browsers to trust QWAC certificates issued by EU-designated trust service providers, even if those providers did not meet the browser vendors’ independent compliance standards. Mozilla helped coordinate the open letter from more than 500 security researchers opposing the provision. Mozilla’s argument was explicit: mandatory browser trust for government-designated CAs creates a surveillance capability for any government that can influence its designated TSPs.

Mozilla’s 2019 removal of the EV green bar from Firefox preceded Chrome’s similar change and was consistent with Mozilla’s position that certificate validation level does not meaningfully signal site trustworthiness to consumers. Mozilla’s reasoning was different from Google’s: Google removed the green bar because most of the web was HTTPS and the visual distinction was no longer informative. Mozilla removed it because the distinction gave users a false sense of security that was not supported by the evidence of EV’s protective value against phishing and fraud.

Microsoft: Enterprise Compatibility and Institutional Trust

Microsoft’s approach to SSL trust governance is shaped by its enterprise customer base in a way that is structurally different from Google, Apple, and Mozilla. Google’s users are consumers who update Chrome silently and automatically. Apple’s users are hardware owners who depend on iOS app distribution. Mozilla’s users self-select for open web values. Microsoft’s users are IT administrators at organizations running Windows in regulated industries, government agencies, and large enterprises with complex PKI dependencies.

The Windows root store is the most consequential single trust store in enterprise computing because enterprise endpoints run Windows and enterprise certificate deployments depend on the Windows store. When Microsoft moves slowly on CA distrust, it is because enterprise Windows deployments have certificate dependencies that take time to migrate. The Entrust distrust of 2024 had three cutoff dates: Google Chrome November 11, Apple November 15, Mozilla November 30. Microsoft’s was later, consistent with the pattern of Microsoft giving enterprise deployments the most migration time.

The Federal Public Key Infrastructure (FPKI) integration is the clearest expression of Microsoft’s institutional trust posture. FPKI certificates, issued by US government CAs, are trusted by Windows but not by Chrome, Firefox, or Safari. This trust is for US government internal use: access to government systems from government-managed Windows endpoints. The FPKI roots are not in consumer browser trust stores and are not intended to be. Microsoft maintains this separate trust chain because its enterprise government customers need it.

Microsoft Edge’s extended retention of EV visual indicators after Chrome and Firefox removed them reflects the same enterprise priority. Enterprise IT policies and compliance frameworks reference EV certificates specifically. Enterprise security teams check whether vendor websites have EV. Removing the EV indicator in Edge before enterprise IT departments had updated their own policies would create compliance audit questions. Microsoft moved when the enterprise market was ready to move with it, not when the security research community decided the padlock was misleading consumers.

Where the Four Agendas Collide: Three Case Studies

Case Study 1: The Entrust Distrust of 2024

The Entrust distrust is the clearest recent example of the four agendas producing four different behaviors on the same event. Google announced distrust on June 27, 2024. Google set Chrome’s SCT cutoff at November 11, 2024. Apple followed with November 15. Mozilla followed with November 30. Microsoft followed later.

The sequence reflects each vendor’s priorities. Google moved first because Google monitors CA compliance through CT logs and had the strongest evidence of Entrust’s pattern of compliance failures. Apple followed quickly because its conservative CA trust posture means it moves decisively on distrust events. Mozilla followed, with the privacy consideration that long delay would allow continued surveillance capability from a CA with documented compliance failures. Microsoft moved last, because its enterprise customers needed the longest migration window.

The outcome for buyers: Entrust certificates issued after each browser’s cutoff date were blocked in that browser. A site with an Entrust certificate issued November 12 would work in Apple’s Safari (cutoff November 15) but not in Chrome (cutoff November 11). For four days, Entrust certificate validity varied by browser. This was not an error. It was four different entities each exercising their independent root store authority on different timelines.

Case Study 2: The Apple 47-Day Announcement

Apple’s March 2025 announcement that it would require maximum TLS certificate validity of 45 days created a fait accompli that the CA/B Forum then formalized. This is a structural feature of how unilateral root store authority interacts with multi-stakeholder governance.

CAs who might have opposed the 47-day ballot at the CA/B Forum (because shorter validity means more renewals which disrupts their customers) faced a different political situation after Apple moved. Opposing the ballot meant opposing a policy Apple had already set. Any CA that did not comply with Apple’s announced policy would lose trust in Safari. The ballot passed, with 47 days instead of 45 and a longer timeline, but the direction was set before the vote.

Google had been advocating for shorter validity periods for years. Apple’s unilateral action effectively resolved the CA/B Forum debate in favor of the position Google and Apple shared, before the forum voted. Microsoft and Mozilla participated in the subsequent ballot that formalized the trajectory. The multi-stakeholder forum process concluded with the result that the two largest root store operators by device count had already determined.

Case Study 3: eIDAS 2.0 Article 45

The eIDAS 2.0 Article 45 dispute illustrated the most extreme form of the browser vendors’ independence assertion: the refusal to subordinate their trust decisions to government authority. The EU’s draft regulation proposed that browsers must trust QWACs from EU-designated trust service providers.

Mozilla organized the security researcher opposition and published clear reasoning. Google’s Chrome team also opposed the provision, citing the independence of browser root stores as a security mechanism. Apple’s stance was implicit in its absence from the compromise negotiations. Microsoft, whose enterprise customers include many EU organizations, navigated the issue more carefully.

The final text was modified to preserve more of the CA/B Forum framework. The resolution was not that the EU backed down completely but that the browser vendors’ position, articulated most forcefully by Mozilla and supported by Google, established that browser trust is a security decision, not a political one, and that government designation alone cannot compel browser trust. This position is the structural assertion of independence that all four browser vendors exercise, with different emphases, across every SSL policy dispute.

What the Four-Agenda Landscape Means for Certificate Buyers

Understanding browser agendas clarifies why certificate policy changes arrive seemingly without warning and why they keep coming.

• Shorter validity periods are permanent: Apple and Google both want them. Mozilla has no objection. Microsoft will follow the enterprise market as it adapts. The 47-day trajectory is not the final destination; it is the 2029 waypoint. Plan certificate operations around automation now.
• CA distrust events will continue: Google monitors CA compliance through CT logs continuously. When Google finds a pattern of compliance failures, it acts. Apple follows. Mozilla follows. Each distrust event requires the affected CA’s customers to migrate. Multi-CA strategy reduces blast radius.
• PQC migration will be driven by Google first: Google deployed PQC hybrid key exchange in Chrome in August 2023. Apple is integrating PQC into its hardware security model. Mozilla is focused on algorithmic diversity. Microsoft is focused on FIPS validation. When the CA ecosystem begins issuing ML-DSA certificates, Google will likely be the first browser to require them.
• Enterprise deployments have more time: when Apple and Google move first on any policy, enterprise Windows deployments get a longer runway because Microsoft moves last. For organizations with complex Windows enterprise PKI deployments, Microsoft’s slower pace provides adaptation time that Chrome and Safari users do not get.
• Government-mandated CA trust will not succeed: the eIDAS 2.0 precedent established that browser vendors will collectively resist government-mandated trust inclusion. China’s CNNIC distrust, Russia’s domestic CA exclusion, and the eIDAS 2.0 resistance share a common principle: browser trust decisions belong to the browser vendors, not to governments.