Google Trust Services Free SSL vs Let’s Encrypt in 2026: What Developers Actually Need to Know

If you found a Google Trust Services certificate on your domain and you did not configure it, you are almost certainly on Cloudflare, Firebase Hosting, or Google Cloud. GTS certificates appear automatically on these platforms. You did not switch from Let’s Encrypt; the platform chose GTS as one of its certificate providers.

If you are actively evaluating GTS as a Let’s Encrypt alternative for your own ACME configuration, this article covers what GTS actually offers, the critical operational warning in Google’s own documentation, the specific use cases where GTS is better than Let’s Encrypt, and the use cases where neither free option is the right answer.

What Google Trust Services Actually Is

Google Trust Services is Google’s own Certificate Authority, operated since 2017. GTS issues certificates for all of Google’s own services (google.com, youtube.com, gmail.com) and offers a public-facing ACME API for external developers. The GTS ACME API became generally available at no cost in May 2023 via the Google Security Blog announcement. Documentation was updated April 7 and April 29, 2026, confirming active maintenance.

Two important distinctions from Let’s Encrypt and ZeroSSL:

• GCP account required: the GTS ACME API requires a Google Cloud Platform account for authentication. It is not a universal free ACME endpoint available to any server operator regardless of cloud affiliation. This is a meaningful operational difference. A developer running a server on DigitalOcean, Hetzner, or a dedicated server without GCP involvement needs to create a GCP account and authenticate specifically for GTS ACME access.
• Google-operated infrastructure: Let’s Encrypt is operated by ISRG, a nonprofit. ZeroSSL is operated by the Stack Holdings group. GTS is operated by Google. For organizations with policies about data residency, cloud vendor dependency, or Google-specific concerns, this matters.

Where Developers Encounter GTS Certificates Without Configuring Them

Most developers who search ‘Google Trust Services vs Let’s Encrypt’ are not looking at their own ACME client configuration. They are looking at a certificate that appeared on their domain and wondering what it is. GTS certificates appear automatically in several infrastructure contexts:

• Cloudflare: Cloudflare uses both Let’s Encrypt and GTS to provision Universal SSL certificates for domains on its free and paid plans. Cloudflare selects the CA automatically. You may see either CA in certificate details on different Cloudflare-managed domains. This is Cloudflare’s operational decision, not yours.
• Firebase Hosting: Google’s Firebase Hosting provisions GTS certificates automatically for custom domains. No configuration required or available to the hosting user.
• Google Cloud Certificate Manager: GCP’s managed certificate service uses GTS for certificates provisioned within the GCP ecosystem. Organizations using Certificate Manager for GKE Ingress, Cloud Load Balancing, or Cloud Run get GTS certificates.
• Google Sites and Google Workspace: custom domains connected to Google-hosted services receive GTS certificates.

If you see a GTS certificate on a Cloudflare domain and want to understand why Cloudflare chose GTS over Let’s Encrypt for that specific domain: Cloudflare’s certificate selection algorithm is not fully documented. Cloudflare paid plans (Advanced Certificate Manager) allow you to select the CA; free plans use Cloudflare’s automatic selection. GTS is not ‘better’ or ‘worse’ than Let’s Encrypt in Cloudflare’s usage; both are simply available CAs in Cloudflare’s provisioning pool.

What GTS Offers That Let’s Encrypt Deliberately Does Not

For developers actively choosing to configure GTS ACME rather than Let’s Encrypt, three capabilities differentiate GTS:

• IP address certificates: Let’s Encrypt issues certificates for domain names only. GTS issues certificates for both domain names and IPv4 and IPv6 addresses. This matters for IoT devices, internal load balancers, Kubernetes pods using IP-based routing, and any system accessed by IP address rather than domain name. Let’s Encrypt’s restriction is a deliberate mission scope decision, not a technical limitation.
• Certificate redistribution rights: Let’s Encrypt’s terms of service restrict redistribution of certificates to third parties in certain contexts. GTS explicitly allows certificate redistribution. For multi-tenant SaaS platforms that provision SSL for customer domains (a platform offering custom domain support to hundreds or thousands of customers), redistribution rights are necessary. This is a meaningful enterprise use case distinction.
• Google infrastructure trust posture: for some enterprise environments with established Google Workspace or GCP vendor relationships, having certificate infrastructure operated by Google may simplify security review. This is an organizational consideration, not a technical one.

The Critical Warning in Google’s Own Documentation

Google’s documentation for GTS contains an operational warning that is not present for Let’s Encrypt and represents the most important operational difference between the two CAs:

“Developers of applications and services connecting to Google services must take this into consideration and never hardcode Intermediate or Root Certificate Authorities. Developers should instead build a robust mechanism to update the set of CAs trusted by their applications and services.”

Source: pki.goog/faq   Google Trust Services FAQ (current)

Google’s documentation states explicitly that certificate chains cannot be considered static and that certificate type may change at any time. Clients must be able to handle both RSA and ECDSA certificates. This is a significant operational requirement. For an application that validates GTS certificates specifically, any chain rotation by Google requires an update to the application’s trust store or pinned certificate configuration.

Let’s Encrypt’s approach is more stable: ISRG publishes its root certificate changes with advance notice, maintains long-lived roots, and has a documented cross-sign strategy specifically to maintain compatibility with legacy devices. Google’s infrastructure-first approach means GTS chain management prioritizes performance and Google’s own operational needs, with the burden on developers to handle changes.

If your application or system uses certificate pinning with GTS certificates, Google’s documentation is a direct warning: chains can change at any time. Any pinned intermediate or root will break when the chain rotates. Do not pin GTS certificates. This applies to mobile applications, IoT firmware, and any service that validates TLS certificates against a pinned chain rather than a dynamic trust store.

Reliability and Rate Limits: What Is and Is Not Documented

Let’s Encrypt publishes its rate limits explicitly: 50 certificates per registered domain per week, 5 failed validations per account per hour, 300 new orders per account per 3 hours. GTS does not publish equivalent rate limits in its public documentation. For developers evaluating GTS as an ACME source at scale, the absence of documented rate limits means relying on empirical testing rather than planning from specifications.

GTS has not experienced documented major ACME outages comparable to Let’s Encrypt’s July 21, 2025 complete API outage or the May 8, 2026 issuance halt. This could mean GTS is more reliable, or that GTS has a smaller active user base with fewer operational incidents surfaced publicly. The Let’s Encrypt community is large enough that outages are immediately documented, analyzed, and post-mortemed publicly. GTS incidents, if they occur, may not surface in the same way.

The Browser Compatibility Caveat

GTS’s March 2025 alternate chains update documentation notes that GTS Root R1 is in modern trust stores but ‘devices and clients older than 2018 may not be compatible without a trust store update.’ Let’s Encrypt’s original compatibility challenge with older Android devices was solved through cross-signing with IdenTrust. GTS uses a different approach: it provides alternate chain URLs during the ACME download step, allowing ACME clients to select the chain appropriate for their device compatibility requirements.

For most public websites in 2026, the pre-2018 device population is negligible. For applications targeting embedded systems, enterprise networks with legacy devices, or specific geographic markets where older hardware is more common, the compatibility caveat merits investigation before deploying GTS certificates.

When to Use Each Option: The Decision Table

When Neither Free Option Is the Right Answer

Both GTS and Let’s Encrypt are free, DV-only, no-warranty, no-SLA options. The choice between them is a reliability and feature trade-off within the free certificate tier. Neither provides:

• OV organizational identity verification: a CA-verified business name in the certificate Subject. Phishing sites cannot obtain OV. Zscaler 2024: 0% of phishing sites use OV.
• Warranty: no financial protection against certificate mis-issuance causing documented financial loss
• Support SLA: community forums only for both (GTS paid tiers aside). No guaranteed response time for certificate emergencies
• Multi-year pricing stability: free tier certificates renew at 90-day intervals indefinitely. Paid multi-year subscriptions lock in pricing and reduce renewal management overhead

For production commercial websites where customers submit personal or financial data, a paid OV certificate from an authorized reseller ($49 to $80 per year from Certera) is the appropriate choice. The difference in cost between $0 (GTS/Let’s Encrypt) and $49/year (Sectigo OV) is the cost of CA-verified organizational identity: the structural separation from the DV certificate category that phishing sites use.

The GTS vs Let’s Encrypt question is worth resolving precisely for GCP users and platform developers who need IP certificates or redistribution rights. For the broader developer audience asking this question, the more useful decision is when to upgrade from any free certificate to a paid OV certificate, which is the question the operational context of collecting customer data actually requires answering.

Frequently Asked Questions

Can I use GTS ACME with Certbot without a GCP account?

No. GTS ACME authentication requires a Google Cloud Platform account. The external account binding (EAB) credentials for GTS ACME are obtained through GCP. If you want a free ACME alternative that does not require any cloud account, ZeroSSL requires only an email registration at app.zerossl.com to get EAB credentials. ZeroSSL is the correct universal ACME fallback for non-GCP infrastructure.

Google issues certificates for google.com. Does that make GTS more trustworthy?

Google uses GTS certificates for its own infrastructure, which means GTS has the operational scale and incentive to maintain reliable CA operations. However, issuing certificates for google.com does not make GTS more trustworthy for your domain’s certificate than Let’s Encrypt. Both CAs are in the same root store programs. Both issue identically trusted DV certificates. The root store standing of both is identical from the browser’s perspective. Google’s self-use of GTS is evidence of operational quality at scale; it does not confer additional cryptographic trust on GTS-issued certificates compared to Let’s Encrypt-issued certificates.

My Cloudflare certificate shows Google Trust Services. Should I switch to Let’s Encrypt?

You do not need to switch. Cloudflare manages the certificate and selects the CA. A GTS certificate on your Cloudflare domain provides identical browser trust to a Let’s Encrypt certificate. The CA difference has no impact on your visitors’ experience. If you want to force a specific CA on Cloudflare, upgrade to Advanced Certificate Manager (paid) which allows CA selection. On Cloudflare’s free plan, the CA selection is automatic and you cannot change it.