Google Trust Services ACME, automated across your estate

GTS issues the certificates. Getting them onto your systems is not its job.

Google Trust Services issues publicly trusted certificates over ACME, from roots that ship in every major trust store. Issuance is clean: register with External Account Binding credentials, request, receive. What ACME hands back is a certificate and a key, on whichever machine asked for them, which is only useful if that machine happens to be the one serving traffic.

CertKit registers against GTS once, renews every certificate centrally, and the CertKit Agent installs each renewal across your servers and appliances and confirms it is being served. With certificate lifetimes compressing toward 47 days and renewals running roughly twelve times a year, that is the half of the job that keeps coming back.

Start free trial Watch demo

GTS external account keys are single-use

This is the detail that catches people scaling past their first host. An external account key minted with gcloud publicca external-account-keys create registers exactly one ACME account. It is not a credential you distribute; it is consumed by the registration that uses it.

On one server that is invisible. Across a fleet it means a fresh key per client, generated through a Google Cloud command, by someone with the right IAM permissions on the project. Rebuild a host and you need another. It quietly makes certificate provisioning depend on cloud IAM access for machines that may have nothing to do with Google Cloud.

Registering centrally sidesteps the whole arrangement. CertKit consumes one external account key at setup, and the servers never register with GTS at all, so adding or rebuilding a host is not a Google Cloud operation.

What running GTS ACME yourself involves

The do-it-yourself version, once you have EAB credentials:

Mint a single-use external account key per client, and again per rebuild. One key registers exactly one ACME account, so every host running a client needs its own, generated through gcloud publicca external-account-keys create — and a replaced or reimaged server needs a fresh one. Cloud IAM becomes a dependency for machines that have nothing to do with Google Cloud.
Install and maintain the client on each host. Same rollout, patching, and configuration burden as any per-server ACME deployment, multiplied by the estate.
Give the client DNS credentials for wildcards. DNS-01 is the only path to a wildcard, and the usual implementation puts a DNS provider API token on the web server so the client can write challenge records.
Write the post-deploy hooks. Convert, place, reference, reload, per platform. The hook only runs at renewal, so a broken one stays broken quietly.
Add monitoring and a central record. Neither ships with the client, and both are what you actually need when a CA has a bad week.

None of it is difficult in isolation. It is just per-host work that multiplies, and with lifetimes heading toward 47 days and renewals running roughly twelve times a year, nobody is supervising the cadence closely enough to catch the host that stopped.

At 47-day lifetimes, per-host ACME stops being maintainable. Here's how CertKit runs Google Trust Services centrally instead.

How it works

 Google Trust Svcs        CertKit             Your systems
┌──────────────┐   ┌─────────────────┐   ┌──────────────────┐
│              │   │  one external   │   │                  │
│  ACME  ◄─────────── account key,   │   │  ┌─────────────┐ │
│              │   │  used once      │   │  │CertKit Agent│ │
│      │ issues│   │                 │   │  └──────┬──────┘ │
│      ▼       │   │                 │   │         │        │
│  Certificate ───►│  Renew on time  │   │         ▼        │
│              │   │       │         │   │  nginx    [x]    │
│              │   │       ▼         │   │  HAProxy  [x]    │
│              │   │  Deploy ───────────►│  K8s      [x]    │
└──────────────┘   └─────────────────┘   └──────────────────┘
   publicly           one CNAME             deployed and
   trusted roots      delegation             verified

The servers never talk to GTS. CertKit holds the one external account key, validates through a single delegated CNAME per domain, and the agent receives finished certificates rather than negotiating for them.

CertKit has been a fantastic solution for automating our environment’s SSL/TLS certificates. With a single pane of glass for centralized management, visibility, and monitoring and the highly customizable interface for granular control over individual systems, we have found great value in reducing the time and complexity of managing an ad-hoc ACME solution for individual certificate automation.

Seth Allums, Lead Systems and Information Security Engineer, Clackamas Community College

What CertKit handles

Issue and renew from GTS centrally. One EAB registration held by CertKit instead of an ACME account registered on every host.
Renew with margin, centrally. One schedule for every certificate, with enough lead time that a failed attempt can retry long before expiry.
Keep cloud IAM out of your server builds. One external account key is consumed at setup. New and rebuilt hosts get certificates without anyone running a gcloud command.
Issue wildcards without DNS credentials. Delegated CNAME validation covers wildcard names, so no DNS provider API token is handed to an ACME client.
Deploy anywhere, not only Google Cloud. The CertKit Agent installs to on-premise servers, appliances, and other clouds in the format each expects.
Verify what is actually being served. A TLS connection after each renewal, checking serial, names, and expiry against what was deployed.
Track which CA signed what, and when. With more than one issuer in play, the log answers a question a single-CA setup never has to ask: which authority is behind the certificate on this host right now. As renewal cycles shorten, that answer changes often enough to be worth recording.

Setup takes about ten minutes

Delegate validation with one CNAME. One record per domain, covering wildcards, added once.
Create an external account key. Run gcloud publicca external-account-keys create against your Google Cloud project and copy the Key ID and HMAC it returns.
Add Google Trust Services as an issuer in CertKit. Enter the key details and a contact address. Existing certificates can then be moved to it without redeploying anything.
Put the agent on each target. One install command per system, then choose that platform's deployment template.

See the issuer documentation →

Why not stay inside Google Cloud tooling?

If everything you run sits behind a Google Cloud load balancer, Google's own managed certificates are the path of least resistance. They are provisioned and attached to the resources that use them with no ACME, no client, and no separate system.

The argument only appears when the estate is mixed, which most are. An on-premise nginx box, a FortiGate at the branch office, an IIS server nobody has migrated, and a Kubernetes cluster on a different cloud all need the same certificates and none of them are Google Cloud resources. Managing the Google-native half in one place and the rest in another produces two inventories and one blind spot.

CertKit keeps GTS as an issuer while the deployment layer covers everything, wherever it runs.

Google Trust Services is one issuer among several

CertKit is not tied to any one certificate authority. It issues from GTS alongside Let's Encrypt, Sectigo, DigiCert, GoDaddy, and ZeroSSL, plus a private CA for internal hostnames and mTLS client certificates. Monitoring spans all of them from one inventory.

See all integrations

Start automating Google Trust Services certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing