Let’s Encrypt ACME: Automate Certificates and Manage Renewals Securely

ACME Process and Separate Key Roles

ACME standardizes communication between a client and the certificate authority, not the entire operating environment. The client first creates an ACME account and then places an order for one or more domain names. The server requires authorization for each identifier. Only after authorization is successful can the client finalize the order with a Certificate Signing Request (CSR) and retrieve the issued certificate.

1. Generate an account key or use an existing ACME account, and create the order.
2. For each requested identifier, provide the specified challenge and wait for authorization.
3. Generate a separate key pair for the certificate, use it to create the CSR, and finalize the order. The public key in the CSR must not match the account key used to authenticate the finalization request.
4. Retrieve the certificate and certificate chain, store them securely, and distribute them to the designated TLS endpoints.

The ACME Account Key authenticates the client for the account to the ACME server and signs the protocol messages. The private key used in the CSR, on the other hand, belongs to the subsequent TLS identity. RFC 8555 requires two distinct key classes: The public key in the CSR must not correspond to a known account key and, in particular, must not be identical to the account key that authenticates the finalization request. The client and server must verify this separation.

With DNS-01, there is a third sensitive component: the authorization for the DNS API. Let’s Encrypt points out that having full DNS API credentials on a web server significantly increases the impact of an attack. As an operational security measure, the token should therefore be allowed to modify only the necessary challenge records; alternatively, DNS validation can be performed on a separate system.

Account keys, certificate keys, and DNS access constitute distinct trust domains. Using different key pairs for the account and the certificate is a protocol requirement; their separate storage, strictly limited access rights, and independent rotation processes are also important operational measures. Thus, a compromised DNS token does not necessarily mean access to either the private certificate key or the ACME account.

Automation does not eliminate incorrect prerequisites. An unreachable port, incorrect routing, an inappropriate DNS delegation, or overly broad access rights remain operational issues, even if order creation is automated. ACME streamlines the repeatable process; however, operators must reliably implement a permissions framework, the required separation of account and certificate keys, secure storage, and control over the certificates actually issued within their environment.

The Right Challenge for the Infrastructure

The challenge determines how a certification authority verifies control over an identifier. It should therefore be derived from the network path, DNS management, and TLS termination, not from a blanket preference for a client tool. HTTP-01, DNS-01, and TLS-ALPN-01 specify different types of verification and, accordingly, place different demands on infrastructure and permissions.

For a single, publicly accessible website, HTTP-01 usually the most direct way. The client makes a resource available under /.well-known/acme-challenge/ that retrieves Let’s Encrypt via port 80. If a domain points to multiple A or AAAA records, this resource must be accessible on all systems that the validation request might reach. Otherwise, a validation error will occur occasionally.

Wildcard certificates for *.example.org On the other hand, they absolutely require DNS-01. To do this, the client publishes a TXT record at _acme-challenge.example.org. This works well with many dynamic subdomains, distributed web servers, or a load balancer, because no single HTTP instance needs to serve the validation file. However, a reliable, automatable DNS change is required.

A reverse proxy without a usable port 80 can TLS-ALPN-01 Use this method provided that it controls TLS termination on port 443 and the client being used supports this challenge. Validation takes place via a special TLS connection, not through a standard web file. This method is therefore particularly suitable for specialized proxy or hosting infrastructure, but not as a general replacement for HTTP-01. Wildcards are not supported here either.

No single method is universally superior: HTTP-01 reduces DNS lookups for a simple website; DNS-01 supports wildcards and decouples validation from the web path; TLS-ALPN-01 specifically leverages existing TLS controls. The key is that the chosen challenge works under real-world failover, IPv4, and IPv6 paths and that its permissions align with the respective operating model.

ARI, profiles, and shorter durations

With ACME Renewal Information (ARI) shifts the renewal logic from a locally defined cutoff date to a time window recommended by the ACME server. The client retrieves this information for an existing certificate and selects a random time within the window. This allows renewals to be spread out over time and, in the event of special circumstances, to be brought forward as needed.

ARI is a standardized extension, but it is not an automatic feature of every installed client or hosting panel. Let’s Encrypt can offer new, backward-compatible ACME features on the existing endpoint; whether a specific installation uses them depends on its version and implementation. For larger deployments, it is therefore important to verify whether the client queries ARI, respects the time window, and does not resynchronize renewals.

Let’s Encrypt also assigns certificates to specific profiles. Unless a specific profile is selected, the classic profile is the default and currently has a 90-day validity period. The profile tlsserver has a 45-day validity period, shorter time limits for open authorizations and orders, and a maximum of 25 DNS names. shortlived It also uses short object lifetimes, is valid for about 160 hours, and supports DNS and IP identifiers.

Profile selection also requires client support; it should not be inferred solely from the server documentation. In addition to validity periods and identifiers, profiles also differ in other characteristics. Applications and inventory tools must therefore not implicitly assume a uniform process or the presence of a Common Name in every certificate.

Mathematically, the ratio between 90 days and approximately 160 hours is about 13.5. This does not result in a measurable load, but it does lead to a clear planning consequence: Any disruption in ordering, distribution, or reloading will result in short-term certificates critical much earlier. They are only useful for systems whose entire supply chain is monitored and whose renewal does not depend on manual intervention. For ARI-coordinated renewals, Let’s Encrypt applies special rules regarding rate limits under documented conditions.

Challenge Matrix and Secure DNS Delegation

The selection of the challenge is based on the available infrastructure, not on a general ranking. HTTP-01 requires a publicly accessible response on port 80, DNS-01 requires a controllable TXT record, and TLS-ALPN-01 requires control over TLS termination on port 443. Wildcard names can only be validated with DNS-01.

A website with a single web server is therefore often well-served by HTTP-01. However, if DNS A or AAAA records point to multiple systems, each destination that is actually reached must deliver the expected resource. Otherwise, the result depends on which endpoint the validation reaches. A load balancer or a centrally synchronized challenge store eliminates this problem only if it covers all possible paths.

For DNS-01, the Minimum authorization The goal is to ensure that the ACME client can modify only the necessary challenge entries. The extent to which this restriction is actually possible depends on the DNS provider’s API and authorization model; not every service grants permissions for a single TXT record. If only broad-ranging access remains, validation should be moved to a separate system or a separate challenge zone should be delegated. Access credentials should be stored in a secure repository, separate from certificate and ACME account keys.

For large zones, a separate challenge zone can further restrict permissions. The delegation of _acme-challenge Using a CNAME or NS record, the validation data is moved to a separate administrative zone. The client is then granted edit permissions only within that zone. Before going live, the TXT content and DNS resolution must be verified: A correct API response is not sufficient if resolvers cannot yet see the delegation or the record.

Reliably Automate Renewal and Distribution

Durable Certificate Management does not end with the retrieval of a certificate. In a distributed environment, a central ACME worker triggers the validation process and securely stores the certificate and private key. Only then are the artifacts distributed to the TLS endpoints, where they are verified and activated under controlled conditions. The certificate key used in the CSR must be different from the authenticating ACME account key; how both keys are subsequently stored separately, authorized, and rotated must be specified in the operational concept.

The following table describes a recommended operational concept for the supply chain. RFC 8555 requires that the public key in the CSR not match any known account key and, in particular, not match the account key used to authenticate the finalization request. The specific organizational separation of storage, access rights, and rotation is based on this protocol requirement. Certbot’s deploy hook is intended for actions following successful issuance. Transmission security, destination verification, and external TLS verification must be tailored to the respective infrastructure.

When making changes to panel or DNS integrations, the production chain should not be viewed as a standalone system. This is especially true when managing it via Plesk Updates for Hosting Providers Available functions depend on the Panelstand, extensions, and connected services. The specific capabilities of the ACME client—such as support for additional protocol extensions—also depend on the version and must be tested in the specific combination being used.

With Certbot, a deploy hook can trigger the final step because it runs only after a successful renewal. The following example assumes that the local path points to a verified, executable script that does not require credentials. The script should idempotent Continue working, log any errors, and reload only those services that use the updated certificate.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

The exit status of certbot renew is not proof of a new certificate: Even if nothing needed to be renewed, the command may return a status of 0. Monitoring must therefore independently determine which certificate the public endpoint is actually serving, when it expires, and whether the reload was successful.

CAA, Profiles, and Certificates for IP Addresses

A CAA record is a Exhibition Railings: It specifies which certification authorities are permitted to issue certificates for a domain. In addition, the policy can specify the allowed validation method and, via the parameter accounturi Specify the intended ACME account. The current account key authenticates access to this account, but it can be changed through the ACME key change process. Account binding therefore does not replace the protection provided by the current account key or a comprehensive authorization scheme.

The following record line allows Let’s Encrypt for the domain only with DNS-01 validation. It is only suitable if DNS-01 is set up automatically and the challenge zone is managed reliably. Anyone who later wishes to use HTTP-01 for a single website or TLS-ALPN-01 for a reverse proxy is intentionally blocking this certificate issuance with the restriction shown here.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

A single line does not necessarily describe the entire CAA Policy the zone. Multiple records of the same type have a cumulative effect: If one of them permits issuance, that permission remains in effect even if other records in the zone have stricter requirements. For wildcard certificates, it is also necessary to check whether issuewild-records exist. Without such records, the following applies: issue including wildcards; existing issuewild-Entries, on the other hand, control wildcard issuance separately. Therefore, the complete, valid record set for the name being checked is always the determining factor.

Certificates for public IP addresses are different from domain certificates. Let’s Encrypt supports IP identifiers in the profile shortlived; HTTP-01 and TLS-ALPN-01 are suitable for validation. DNS-01 cannot validate an IP address. The short validity period of approximately 160 hours therefore requires continuous automated renewal, distribution, and delivery monitoring.

The "shortlived" profile is therefore suitable for interfaces that are directly accessible via IP only if every step works without manual intervention. It is not a simplified version for systems that are maintained only occasionally. Furthermore, the ACME client used and the target environment must support the selected profile and challenge; the fact that a feature is available on the ACME service does not guarantee that every client version supports it.

Monitoring and Troubleshooting First in Staging

Troubleshooting ACME issues starts with the validation method actually being used, not by requesting a new certificate. For changes to the client, routing, firewall, or DNS, Let’s Encrypt’s separate staging endpoint is the appropriate place to test. The staging environment has its own, significantly higher limits, but it is not unlimited; the test certificates issued there are not publicly trusted. Although new protocol features may be available at the ACME endpoint, support for the installed client must still be verified separately.

For HTTP-01, you must first check whether the affected domain is publicly accessible via port 80 and whether the requested file is located at /.well-known/acme-challenge/ to the target system. Multiple A or AAAA records make the test more challenging: Each endpoint that can actually be reached must provide the appropriate challenge file. Typical causes include incorrect virtual host routing, an upstream proxy, a firewall rule, or unsynchronized containers.

TLS-ALPN-01, on the other hand, requires control over TLS termination on port 443. If an error occurs, you should verify which load balancer or proxy is accepting the connection, whether it is providing the certificate required for the challenge, and whether a regular TLS service is overriding the process. A successfully generated local certificate file does not prove that the publicly accessible endpoint is using it.

For DNS-01, the name and content of the TXT record are listed under _acme-challenge check separately. The record must be published in the delegated or authoritative zone; furthermore, the delegation chain must be correct if a separate challenge zone is used. Repeated failed attempts due to typos, changes that are not yet visible, or incorrect delegation should first be analyzed in the staging environment.

Effective Monitoring It does more than just monitor the expiration date in the ACME worker's storage. It independently checks the delivered hostname, the remaining validity period of the certificate stored there, and whether the reload was successful after an update. An alert should also be triggered if a renewal fails or if an endpoint continues to serve the old certificate despite successful issuance. For planned changes to hosting servers, the article adds Planning cPanel and WHM Updates Safely the necessary operational planning.

Rate Limits and Renewals in the Portfolio

In a certificate portfolio, rate limits are a design constraint of the SSL Automation. Daily forced renewals or jobs that start simultaneously generate unnecessary orders and can trigger limits. This is especially true when an infrastructure error affects many domains at once: Retry attempts do not resolve missing challenge files or incorrect DNS settings, but they do increase the number of failed validations. Errors must therefore be isolated before the next production run.

ACME Renewal Information, in brief ARI, replaces fixed local thresholds with a renewal window recommended by the ACME server for an existing certificate. The ARI-enabled client retrieves the renewal information and selects a random time within that window. A scheduler can launch the client periodically, but does not evaluate ARI itself. The client must use the recommended window and Retry-After take these factors into account and, in the event of errors, adhere to appropriate backoff and retry intervals. More frequent scheduler runs must therefore not result in unchecked retries of failed jobs.

For Let’s Encrypt, ARI-coordinated renewals may be exempt from rate limits under the documented conditions. Among other things, the new request must contain at least one identifier of the certificate to be replaced, and that certificate must not have already been replaced via ARI. This is not a general approval for arbitrary new requests: Changes to the certificate scope must be handled separately from a technical and operational standpoint.

In particular, a shortened or modified SAN list does not automatically constitute a renewal of the existing certificate. A request containing only a subset of the existing names may generate a separate certificate, while the old one remains valid. The inventory should therefore include the certificate ID, the complete list of identifiers, associated endpoints, and the renewal process. Before planning a SAN change, a decision must be made regarding which services will be migrated and when certificates that are no longer needed will be removed.

When multiple workers are involved, clearly defined responsibilities prevent duplicate orders for the same inventory. It is advisable to use a central scheduler or a coordinated lock, maintain traceable logs, and implement staggered retries after an error. Random selection within an ARI window is not a substitute for this control mechanism; rather, it primarily reduces the concurrency of regular refreshes.

Choose the Right Operating Model Based on Risk

For a single, publicly accessible website, HTTP-01 is usually the simplest operating model. The web server must reliably handle port 80 and serve the challenge file from the expected path. This model does not support wildcards and becomes fragile when multiple independent targets respond to the same domain. It is therefore particularly useful when web routing, certificate storage, and TLS delivery are centralized at a clearly controlled location.

DNS-01 is the ideal model for wildcards, dynamic subdomains, and distributed TLS endpoints. The prerequisite is not merely DNS access, but the ability to securely and automatically modify the required TXT record. A token with the narrowest possible scope or a delegated challenge zone minimizes the impact of a compromised system. The level of granularity achievable depends on the DNS API. Delegations must be documented as a production dependency, monitored, and provided with a recovery path.

TLS-ALPN-01 is suitable for operators who want to specifically control TLS termination on port 443, such as on a reverse proxy or load balancer. This method is neither a blanket replacement for HTTP-01 nor does it support wildcards. Its practical usability also depends on the specific client and proxy implementations. Before deployment, it is therefore necessary to verify whether the software can generate the challenge, deliver it, and cleanly remove it upon completion.

The shortlived profile is only suitable for systems with seamless end-to-end automation. Let’s Encrypt specifies a validity period of approximately 160 hours for this, as well as DNS and IP identifiers; compared to the standard profile with a 90-day validity period, this significantly increases the required renewal frequency in theoretical terms. Every step of the process—from ordering to distribution, reloading, and external verification—must therefore function reliably. Choosing a profile also requires that the ACME client being used actually supports that profile.

Regardless of the model, professional Certificate Management A complete inventory, securely managed keys, and DNS access with minimal permissions. The account key authenticates the client for the ACME account; the private key used in the CSR is part of the TLS identity. RFC 8555 prohibits the use of the public account key in a certificate: In particular, the key in the CSR must not match the account key that authenticates the finalization request. The separate storage, assignment of permissions, and rotation of these key classes, as well as revocable access rights and a tested fallback to the previous certificate, are part of the rights management and emergency response plan.

A successful ACME run should not be the only criterion for success. The delivery check must determine, outside the worker, which certificate is presented by a genuine TLS endpoint. For distribution and reload steps, actions that are triggered only after a successful renewal are appropriate; Certbot provides a deploy hook for this purpose. Its script should be idempotent, log errors, and reload only those services that actually use the renewed certificates.