ACME Server and ARI: Zero-Touch Certificate Renewal for Internal Servers

The problem with internal server certificates

External certificates — those issued for public-facing web servers — have benefited from ACME automation for years. A certbot cron job on a Linux server handles Let's Encrypt renewals automatically. The challenge has always been internal servers: machines on private networks, Windows servers, load balancers, and internal APIs that need TLS certificates but cannot directly reach an external CA, do not run a full web stack for HTTP-01 challenges, or operate behind firewalls that make DNS-01 automation difficult.

The standard answer has been a private CA with manual workflows, or pointing each server directly at an external ACME CA. Both approaches share the same failure mode: no central visibility. You end up with scattered ACME accounts per server, no consolidated renewal audit trail, and no mechanism to coordinate when things go wrong. As the CA/Browser Forum's SC-081 ballot shortens maximum certificate lifetimes to 47 days by 2029, that approach becomes increasingly untenable. The guide on avoiding expired certificates covers the operational failure modes that emerge without centralised renewal oversight.

ACME Server (RFC 8555): CertControl as the ACME endpoint

CertControl's ACME Server turns CertControl itself into an RFC 8555-compliant ACME endpoint. Internal servers running certbot, acme.sh, win-acme, or Posh-ACME point to CertControl instead of directly to Let's Encrypt or another CA. CertControl forwards the certificate order to a configured upstream CA (Let's Encrypt, ZeroSSL, or your private CA), handles the challenge, and delivers the signed certificate back to the requesting server — including automatic installation when certbot or win-acme manages the service.

The practical benefits:

• Central account management. One upstream CA account in CertControl serves all internal servers. No per-server ACME account registration, no scattered credentials.
• No direct CA access required. Internal servers only need to reach CertControl. CertControl handles the outbound CA communication, making deployment behind strict egress firewalls straightforward.
• Full lifecycle visibility. Every renewal request, issued certificate, and failure surfaces in CertControl's certificate inventory — alongside your externally monitored certificates. No separate tooling to check.
• Private key security. ACME account private keys are stored encrypted with AES-256-GCM and never leave CertControl. Servers receive signed certificates, not the CA credentials.

HTTP-01 challenges are handled automatically. DNS-01 validation is supported for certificates that require it — including wildcard certificates — via the standard two-step flow. For a broader overview of what this fits into, see certificate lifecycle management.

ARI (RFC 9773): coordinated fleet renewal and mass revocation signalling

ACME Server solves the how of internal renewal. ARI solves the when.

Without ARI, every certbot instance renews when its local schedule says to — typically when fewer than 30 days remain on the certificate. This works fine under normal conditions. It breaks down in two scenarios that every fleet operator eventually faces:

• Mass revocation. A CA revokes a batch of certificates due to a mis-issuance. All 200 servers need to renew within hours, not days. Without ARI, each server is waiting for its own timer to count down. With ARI, you click Force all early in the Renewal Windows tab and every client sees an active renewal window on its next scheduled poll — typically within hours for certbot's default cron interval.
• 47-day certificate lifetimes. A 47-day certificate leaves only a 10–15 day window before the "renew when 30 days remain" threshold triggers. Stagger renewals across a large fleet and you lose the ability to rotate certificates without downtime — some servers renew too early, some too close to expiry. ARI gives the server precise control: it signals the optimal window to each client individually.

ARI is implemented as a public endpoint: GET /acme/renewalInfo/{certId}. CertControl computes a default window that starts at 2/3 of the certificate's lifetime and ends 7 days before expiry. Administrators can override this window for any certificate — delay renewal past a release freeze, bring it forward before a key rotation, or attach a status page URL that ARI-aware clients can display to operators.

Renewal Windows: the admin interface

The Renewal Windows tab in Infrastructure → ACME Server shows every certificate issued through your ACME Server, with its current window, status (Active / Revoked), and whether a manual override is in effect. From here you can:

• Set a custom override window with an optional explanation URL
• Force early renewal on a single certificate — sets the window to a 24-hour span starting now
• Force all early — bulk-updates every active certificate in one operation
• Clear any override to revert to the calculated default
• Backfill certIDs for certificates issued before ARI support was added — one click covers your entire existing inventory

Overrides take effect on the client's next renewal check — typically within hours for certbot's default cron schedule. If you need faster response, trigger certbot renew --force-renewal directly on the affected server.

Client support

ARI is supported by certbot 2.9+, acme.sh, and win-acme. Clients that do not support ARI simply ignore the renewalInfo key in the ACME directory and fall back to their configured schedule — so enabling ARI has no negative impact on older clients.

The ACME Server is compatible with any client that speaks RFC 8555: certbot, acme.sh, win-acme, Posh-ACME, Caddy, and others. Clients connect to your CertControl instance's /acme/directory endpoint during account registration — no special configuration beyond the server URL.

Availability

Both ACME Server (RFC 8555) and ARI (RFC 9773) are available on the Scale plan. The ACME Server quickstart covers account setup, client configuration, and first certificate issuance in under 10 minutes. ARI is enabled automatically for all certificates issued through the ACME Server — no additional configuration required. See pricing for a full plan comparison.

Frequently asked questions

What does the CertControl ACME Server do?

It turns CertControl into an RFC 8555 ACME endpoint. Internal servers running certbot, acme.sh, win-acme, or Posh-ACME point to CertControl, which forwards orders to an upstream CA, handles the challenge, and returns the signed certificate — with central account management and full audit visibility.

What is ARI and what problem does it solve?

ARI (Automatic Renewal Information, RFC 9773) tells each client precisely when to renew. It solves coordinated fleet renewal during a mass revocation and gives precise control over renewal timing when lifetimes shrink toward 47 days.

Do internal servers need direct access to the certificate authority?

No. Internal servers only need to reach CertControl, which handles outbound CA communication. This makes deployment straightforward behind strict egress firewalls, and ACME account keys are stored encrypted and never leave CertControl.

How quickly does a forced renewal take effect?

Overrides and Force all early apply on each client's next renewal check — typically within hours for certbot's default cron schedule. For an immediate renewal, run certbot renew --force-renewal on the affected server.

Which ACME clients support ARI?

ARI is supported by certbot 2.9+, acme.sh, and win-acme. Clients without ARI support simply ignore the renewalInfo key and fall back to their configured schedule, so enabling ARI has no negative impact on older clients.