Trustico® Certificate as a Service (CaaS) for Google Cloud installs your SSL Certificate in Google Cloud automatically and keeps it up to date, so it never expires and never needs maintaining by hand. A small job runs once a day inside your own Google Cloud project, issues each SSL Certificate of your subscription, reissues it before it expires and installs the new one, with no further work from you.
The SSL Certificate is installed in Google Certificate Manager, in the classic Compute store, or in both at once, so the one job serves the Google services that read from either store. Once the SSL Certificate is in place, a script can do whatever you want with it in your Google Cloud project, such as putting it on a load balancer, a virtual machine or a Kubernetes cluster. Trustico® supplies scripts for load balancers, and more will follow. You can also write your own.
It suits anyone who uses SSL Certificates with Google Cloud and would rather not track expiry dates or install each one by hand. One SSL Certificate under one subscription, or several of each, run from the same job in exactly the same way.
Daily Operation
Once a day, at the hour you choose, the job starts and looks at each SSL Certificate in its care. It acts only where something is due, and an SSL Certificate is due for reissue about thirty days before it expires.
When one is due, the job first proves that you control its domain names by writing a small temporary record through your Domain Name System (DNS) provider. It then obtains the reissued SSL Certificate, saves it with its Private Key in a private storage bucket in your project, and installs it in each store you chose.
With Certificate Manager, the job updates the one SSL Certificate object in place, so whatever uses it never needs touching again. With the classic Compute store, every reissue becomes a new numbered resource, and whatever uses it then has to be pointed at that resource. A script does this for you, as described under What Falls Outside.
On a day when nothing is due, the job still checks that every SSL Certificate is current and installed, then finishes within a few seconds. If a run ever fails, it is marked as failed in the history of the job, and the next daily run starts again from the beginning. An optional alert, described in the Google Cloud ACME setup guide, can let you know whenever that happens.
Where Your Keys Live
Every Private Key stays inside your own Google Cloud project. The job keeps its account, each SSL Certificate and the Private Key of each one in a private Cloud Storage bucket that you create in your project during setup, and nothing in that bucket ever leaves your project.
The bucket also holds on to earlier versions of its files. When the job replaces an SSL Certificate and its Private Key, the previous ones are still there, so a reissue can be undone if it ever has to be.
The job runs under a service account of its own, which is an identity in your project for a program rather than a person. It holds only the permissions the setup gives it, each for one thing the job does, and has no access to anything else in your project.
The credentials from your subscription and from your Domain Name System (DNS) provider can be kept in Google Secret Manager, the store Google provides for secrets. The job configuration file then names each secret rather than holding it, so the file itself can be stored, copied or shown to anyone assisting you without revealing a credential.
Requirements
Setup needs three things, and each one is worth having ready before you start.
The first is a Google Cloud project, and an account on it with the Owner role. The Editor role is not enough, because it can create the bucket, the service account and the job, but it cannot grant the permissions the setup asks for. If you only have the Editor role, whoever holds the Owner role can make those grants for you.
The second is a Trustico® Certificate as a Service (CaaS) subscription covering every name you want on the SSL Certificate, where a wildcard and its base name count as two names. With the subscription you receive three values : the directory address, the key identifier and the Hash-based Message Authentication Code (HMAC) key. The last two are your External Account Binding (EAB) credentials, and all three go into the job configuration file. Learn About Certificate as a Service (CaaS) 🔗
The third is access to the Domain Name System (DNS) of your domain, through the Application Programming Interface (API) of your provider. The job uses that access to prove you control your names, by writing a small temporary record whenever an SSL Certificate is due. One provider is used per job, and if your domain is on Google Cloud DNS in the same project as the job, no extra credential is needed at all.
The job does this through lego v5.5.2, the Automatic Certificate Management Environment (ACME) client inside it, so your provider must be one that lego supports. The providers lego supports are listed on its own page, which describes its latest release, so a provider is available to this job only if that page shows it as present at v5.5.2 or earlier. Learn About The Supported Domain Name System (DNS) Providers 🔗
Alternative Issuance Methods
Trustico® CaaS for Google Cloud is one of several ways to use a Certificate as a Service (CaaS) subscription. The same subscription and the same credentials also work with each of the methods below, and more than one can be in use at the same time, so you can choose whatever suits each place an SSL Certificate is needed.
If your website runs on cPanel, the Trustico® Certificate as a Service (CaaS) cPanel Plugin brings automated SSL Certificate management into your hosting control panel. It retrieves, installs and reissues your SSL Certificates from within cPanel itself, with no command line. Explore The Trustico® cPanel Plugin 🔗
On your own servers, a standalone Automatic Certificate Management Environment (ACME) client such as Certbot, acme.sh, lego or win-acme requests, installs and reissues SSL Certificates in the same automated way. Explore Automatic Certificate Management Environment (ACME) Clients 🔗
For equipment that cannot run any client at all, the hosted issuance tool issues an SSL Certificate directly in a browser, with nothing to install. Learn About The Hosted Issuance Tool 🔗
Trustico® CaaS for Google Cloud is the right choice when your SSL Certificates are used by Google services, because it runs inside your own project, keeps every Private Key there, and reissues each SSL Certificate with no work from you.
What Falls Outside
Trustico® CaaS for Google Cloud is not a hosted service. You run the job in your own Google Cloud project, under your own account, and Trustico® does not operate it for you.
It is not a web application either. There is no website to sign in to and no screen to click through. Everything the job does is decided by one text file, the job configuration file, and you follow its work in the history of the job in the Google Cloud console, which lists every run.
You keep your own copy of that file. Changing what the job does later, such as adding or removing a domain or a subscription, is an edit to your copy that you apply once more. Google keeps the job built from the file, not the file itself.
The job itself stops once the SSL Certificate is installed in the store. With Certificate Manager nothing more is ever needed, because the one SSL Certificate object is updated in place and whatever uses it never needs touching again.
The load balancer scripts are optional, and a customer who manages their own Certificate Map does not need the Certificate Manager one.
With the classic Compute store, each reissue is a new SSL Certificate resource, and whatever uses it then has to be pointed at the new one. A script does this for you. Trustico® supplies one for load balancers, and you can write your own for anything else. Learn About The Google Cloud Optional Extras Scripts 🔗
Getting Started
Setup is a one-time sequence of seven steps and takes about thirty minutes. You enable the APIs, create the bucket, create the service account, prepare the job configuration file, create the job, run it once, and schedule it daily. Each step is one screen in the Google Cloud console or one command in Cloud Shell, the terminal built into the console, and every reissue after that happens on its own.
Note : The software the job runs is published by Trustico® as a public image under a single name. Your job takes each approved update on its next run, so there is nothing to apply and nothing to edit, and the first line of every run names the version and the build that ran.
The setup guide takes you from nothing to a running job, with every screen, every value and what to do if a run ever fails. It is the document to have open while you work through the steps. Download The Google Cloud ACME Setup Guide File 🔗
Before you begin, the technical page explains each of the seven steps in plain English, what the job configuration file holds, and what happens on every run. Learn About Setting Up the Google Cloud CaaS Job 🔗
Wildcard
Wildcard
Wildcard
