September 2025 - ACME Best Practices

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, 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.
  • The ACME protocol is continually evolving. ACME client software and libraries should be designed to 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.
  • Use Google Cloud project names that clearly tie back to you and your use. company_name-acme-prod is a much better name than aq-fks8f4d or zippyzebra123.
  • 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. We ask that you not use a cron job for renewals. If your renewal trigger is using a cron job, don't 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 won't 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 versus a 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.

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.