ACME is the protocol that lets software request and renew certificates with a certificate authority. It removes repetitive manual work, but it does not remove operational responsibility. Understanding its handoffs helps you interpret a managed hosting feature, choose a client, or locate the stage that failed.

This is a workflow explanation for website operators, not a client implementation tutorial. Before configuring anything, identify who controls your public DNS, hosting endpoint and certificate deployment. On managed hosting, the provider may perform the entire workflow; avoid adding a second independent client until you understand the existing arrangement.

The roles and their handoffs

  1. The client uses an ACME account to request a certificate for specific names.
  2. The CA supplies authorization requirements for the request.
  3. The client and infrastructure make the required challenge response available.
  4. The CA checks the response and, when the requirements are satisfied, can issue the requested certificate.
  5. Your deployment process makes the certificate available to the serving endpoint.
  6. Your monitoring checks that visitors receive a usable certificate.

The ACME standard describes the order, authorization and issuance flow. Account credentials identify the client to the CA; the website certificate and its private key have a separate role in serving TLS. Plan appropriate storage and permissions for both rather than treating every credential as interchangeable.

Choose validation that fits your infrastructure

HTTP-01: answer on the website path

The client publishes a challenge response beneath /.well-known/acme-challenge/. Let’s Encrypt checks it over HTTP on port 80. This method does not issue wildcard certificates. With multiple frontends, the correct response must be available wherever validation requests arrive.

DNS-01: answer through authoritative DNS

The client arranges a TXT record beneath _acme-challenge. This supports wildcard validation and can work without a publicly reachable web server. Reliable automation needs a suitable DNS API or delegated validation arrangement, appropriate permission scope and time for the record to become visible. Protect DNS credentials according to their reach.

Let’s Encrypt documents both methods and their prerequisites. A successful DNS change in your control panel is not itself confirmation that the CA can retrieve the answer.

TLS-ALPN-01: a specialized TLS response

This method uses a special TLS exchange on port 443. The TLS endpoint and ACME client must support it; merely having an HTTPS listener is insufficient. It is an infrastructure choice rather than an automatic fallback for every site. The TLS-ALPN challenge specification describes the required protocol behavior.

Test each boundary deliberately

Start configuration changes in a suitable test environment. Let’s Encrypt staging allows issuance rehearsals, but its certificates are not trusted for normal public browsing. Keep test client state and output separate from production installation paths. Staging still checks real authorization requirements; it is not permission to request certificates for names you do not control.

A client test can exercise validation and issuance without proving that the production server reloads the replacement. Review what your client’s test mode changes and what it skips. Record separately whether you exercised issuance, deployment and the public connection.

Read failures by stage

  • Authorization fails: compare the intended name and chosen challenge with the HTTP route or DNS response.
  • Issuance fails after validation: inspect the client’s exact CA response and documented retry guidance.
  • Issuance succeeds but visitors still fail: inspect installation, service activation and every serving endpoint.
  • Renewal never starts: inspect the scheduler or managed service status before changing challenge records.

Repeated retries without a changed condition rarely explain a failure. Preserve the error and investigate the failing stage. Once issuance and deployment are understood, add an owner, served-certificate checks and alerts using a complete renewal plan.

Sources