To ensure reliable operations, follow the practices in this guide for Google Public CA.
Google Public CA is an ACME based CA. ACME was designed to automate the entire lifecycle
of certificates.
Considerations
* Use a standard ACME client / library that fully automates the certificate lifecycle and is
well-maintained. If you are writing or customizing a client, please keep maintenance needs in mind.
* Your client must support the External Account Binding (EAB) feature of ACME to use Public CA.
See the Public CA tutorial for more information.
* It is not possible to get certificates for RFC 1918 space or internal-only domain names
(e.g. .local) or IP addresses (e.g. 127.0.0.1) as external validators need to be able to access the
address to validate ACME challenges.
* Testing should be conducted against the staging endpoint. You can find it in the Public CA tutorial
linked above.
* The ACME protocol is continually evolving. ACME client software and libraries should be designed
for easy and regular updating. They should also be updated regularly.
Best practices
* Honor retry headers. Your client should respect HTTP 429 responses with a Retry-After interval
specified.
* Use ACME Renewal Information (ARI) so your client can proactively manage certificate renewal for you in
a timely manner.
* Support retrying of challenges. There are many ways for hiccups to occur between the CA validation
servers and targets. It is not uncommon to need a small number of retries.
* Renew certificates when they reach 2/3rds of their lifetime. So at ~60 days for 90-day
certificates. If possible, you want to smooth renewals and avoid batches that are large compared to
your steady state renewal rate. Please do not use a cron job for renewals. If your renewal trigger
is via a cron job, please do not start it on an hour boundary and add some random delay to smooth
requests.
* If speed is a consideration, the HTTP and TLS-ALPN ACME challenges are your best options. Keep in mind,
wildcard certificates can only be obtained using DNS ACME challenges.
* Set and maintain CAA records to enhance security for your domain by controlling which Certificate
Authorities are authorized to issue certificates for your domain. See https://pki.goog/faq/#caa.
* Use CAA account binding (https://www.rfc-editor.org/rfc/rfc8657) for high-security domains.
* Ensure your DNS is globally consistent. GTS follows multi-perspective issuance corroboration
requirements and will not issue if we're not seeing consistent results across globally distributed
views.
* Set up logging and monitoring. A good ACME setup should just work and not need intervention, but
problems may occur from time to time. Make sure you have mechanisms to handle errors.
* Multi-SAN vs. single name per cert - in most cases it is preferable to minimize the number of
names covered by a single cert. Doing so helps keep certificates smaller and minimizes the impact if
a certificate needs to be revoked. Similarly, it is preferable to not use wildcard certificates, but
there are use cases where they are appropriate.
* If you request large volumes of certificates, distribute your requests across multiple hosts with
diverse IPs to minimize the risk of DoS blocking from concentrated requests. Multiple accounts also
minimize single point of failure risks if an account is compromised or access is lost.
* Public CA supports dns-account-01, which is a new ACME challenge type being standardized. It is
useful for service providers who need to validate on behalf of customers.
The guidance at https://github.com/https-dev/docs/blob/master/acme-ops.md is a bit dated, but is still mostly
useful. https://acmeprotocol.dev/ is also a good source of information.