Automate Public Certificates Lifecycle Management via RFC 8555 (ACME)
Product Manager, Core Security
Product Manager, Google Cloud
We’re excited to announce an enhancement of our preview of Certificate Manager which allows Google Cloud customers to acquire public certificates for their workloads that terminate TLS directly or for their cross-cloud and on-premise workloads. This is accomplished via the Automatic Certificate Management Environment (ACME) protocol which is the same protocol used by Certificate Authorities to enable seamless automatic lifecycle management of TLS certificates.
These certificates come from Google Trust Services, the same Certificate Authority (CA) we use by default when we manage certificates on your behalf with the Global External HTTPS Load Balancer. By using the same CA for managed certificates and unmanaged certificates you are assured that both scenarios work equally well across the entire spectrum of devices that use your services.
This also enables Cloud Customers to get a more reliable TLS deployment. It does so by enabling one common certificate lifecycle management story based on ACME to be used without a single point of failure (relying just on one certificate authority). In other words, it is now possible to freely load balance or fail over to multiple ACME CAs with confidence.
How do I use it ?
To use this feature you will need an API key so you can use a feature in ACME called External Account Binding. This enables us to associate your certificate requests to your Google Cloud account and allows us to impose rate limits on a per customer basis. You may easily get an API key using the following commands:
Each ACME implementation differs slightly on how you specify this API key but as an example with the popular Certbot ACME client the configuration looks something like this, to register an account:
After the account is created, you can issue certificates by running:
It is that simple.
For Kubernetes based workloads
If you are using Kubernetes, thanks to cert-manager (another ACME client), it is just as easy. Simply specify the ACME url and External Account Binding details in your configuration. Your ACME client will ensure you always have an up to date certificate for your Kubernetes deployment.
Announcing the Private Preview
We have heard loud and clear that our customers want to use a unified solution for managing their HTTPS certificates which is why we have launched this offering today.
Using this service and Google Trust Services means you will get the same industry leading device compatibility we use for services like YouTube and Google search for your own products and services.
We know you might have some questions about this release so here are our answers to the most frequent questions we hear:
How can I get access?
This feature is now in public preview and all Google Cloud customers have access. Learn more.
How long are the certificates you issue good for?
By default all certificates issued by Google Trust Services are good for up to 90 days; however, ACME allows for clients to request certificates with different validity periods. Using this capability we allow the requestor to get certificates that are good for as little as 1 day, though we would not recommend using anything less than 3 days due to concerns over clock skew and certificate validity overlap.
What forms of domain control verification do you support?
The ACME protocol defines several mechanisms for domain control verification and we support three of them, they include : TLS-ALPN-01, HTTP-01, and DNS-01.
Each of these have different scenarios where their use makes the most sense, for example TLS-ALPN-01 might make sense in cases where HTTPS is not used and the requestor does not have access to dynamically update DNS records. Choose the mechanism that fits your use case best.
Do you support email based domain control verification?
No we do not.
Do you issue wildcard certificates?
Yes we do. Please note, as with other Certificate Authorities you must currently use DNS based domain control verification to get a wildcard certificate.
Do you issue certificates for punycode encoded Unicode domain names?
Not at this time.
Do you issue certificates containing IP addresses?
Yes we do; however, this is currently limited to customers who control an IANA assigned IP address block. Contact your sales representative for more information.
Can I use ACME to get private certificates from Cloud CA Service?
Yes, but not directly. Our partner SmallStep created an ACME Registration Authority (RA) that can be used to get certificates from the Cloud CA Service.
Do you offer certificates from a pure ECC based certificate chain?
Not at this time.
What root certificates do you use?
We list all of our root certificates and intermediate certificates here and we do change which ones we use from time to time.
It is important to also note that we send the appropriate intermediate certificates with every certificate request via the ACME protocol.
Why should I use Google Trust Services instead of another certificate authority?
There are multiple good ACME CAs you may use.
We envision a world where those that deploy SSL use a number of ACME based certificate authorities to enable sites to continue to operate without downtime when one provider has availability issues. If you need a large number of certificates or guarantees on geographic diversity, the GTS CA may be an especially good fit.
It is our hope that by making this service available to cloud customers they will be able to get the benefit of that robustness, and reduce latency for workloads terminating TLS within Google Cloud.
You recently announced Certificate Manager, is this an alternative to that offering?
No it is not. This extends Certificate Manager so that workloads that choose to terminate TLS on their own are able to get certificates from the same CA we use when we manage your certificates for you.
It is our hope that with this ACME API, you will be able to simplify your HTTPS certificate lifecycle management for your workloads.