Let's Encrypt: Renewal Events

Back to Certificates Center main section

Artica renews Let's Encrypt certificates automatically, whether they were issued through the HTTP-01 challenge (port 80 validation) or the DNS-01 challenge (TXT record validation through a DNS provider such as Cloudflare, OVH, Route53…). 
The Renewal events feature adds a persistent, queryable journal of every renewal attempt the appliance performs 
Successes and failures, with the exact ACME error message — and automatically reloads the reverse-proxy websites that use a certificate once it has been renewed.

Before this feature, renewal outcomes were only visible in transient notifications and log files: 
after a daemon restart, there was no way to answer “was my certificate renewed last night, and if not, why?”. The renewal journal answers that question for a full year of history.

Benefits

• Full audit trail 
  Every attempt is recorded with its date, certificate, challenge type, DNS provider, duration and outcome. Entries are kept for 365 days and survive daemon restarts and reboots.
   
• Actionable error messages 
  When a renewal fails, the complete ACME error returned by Let's Encrypt is stored (for example a DNS NXDOMAIN on the _acme-challenge TXT record, or an HTTP 403 on the well-known challenge path). Hover the truncated message to read it in full.
   
• No more stale certificates on the reverse-proxy 
  when Reverse-proxy feature is enabled, each successfully renewed certificate triggers a rebuild of the websites that use it, followed by a single graceful reverse-proxy service reload. 
  The Websites reloaded column confirms it happened.
   
• Both renewal engines covered 
  The journal is fed by the HTTP-01 renewal task (scheduled) and by the DNS-01 auto-renewal manager (6-hour cycle), including renewals triggered manually from the console.
   
• API first 
  Everything shown in the console is available through the REST API for integration with your monitoring.

Use cases

• Morning check after a certificate incident 
  A browser warning on a published website? 
  Open the renewal history and see in seconds whether the last renewal failed and with which exact ACME error, instead of grepping log files.
   
• Proving compliance 
  Export a year of renewal events through the REST API to demonstrate that certificates are rotated automatically and on time.
   
• Diagnosing a DNS provider misconfiguration 
  A revoked Cloudflare token or a deleted DNS zone shows up as a recurring failed entry with the provider name and the DNS error, several weeks before the certificate actually expires.
   
• Verifying the reverse-proxy picked up the new certificate 
  The Websites reloaded check mark tells you the vhosts were rebuilt and reverse-proxy service reloaded; no check mark on a success means nginx is disabled on that appliance or the reload is still pending.
   
• Watching Let's Encrypt rate limits 
  Repeated failed attempts are visible at a glance, letting you fix the root cause before hitting the Let's Encrypt per-domain limits.

Where to find it

Open Your System → Certificates Center. The Let's Encrypt wizard is opened by the Let's Encrypt Certificate button:

Inside the wizard, a new Renewal history tab sits next to the request tabs:

Reading the renewal history

The header line shows the totals — and each label is a clickable filter: click Success or Failed to restrict the table, and the total to show everything again.

Understanding failures

Typical failure signatures:

• urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.<host>
  The DNS provider did not publish the validation record: check the provider credentials and that the zone still exists.
• urn:ietf:params:acme:error:unauthorized :: Invalid response from http://<host>/.well-known/acme-challenge/…: 404  
  The HTTP-01 challenge did not reach the appliance: check that the domain points to this server and that port 80 is reachable from the Internet.
• A certificate bound to the manual DNS provider cannot be renewed unattended  
  Assign an automated provider to it in the DNS providers tab.

A failed attempt is retried on the next cycle automatically; 
the journal keeps one entry per attempt, so a recurring problem is immediately visible as a series of failed rows on the same domain.

Automatic reverse-proxy reload

When the appliance runs the reverse-proxy, renewing a certificate is only half of the job: the websites using it must be rebuilt so reverse-proxy service serves the new certificate. 
This is now automatic for both renewal engines:

• after each renewal batch, every renewed certificate triggers a per-certificate rebuild of the reverse-proxy websites bound to it;
• a single graceful reload of reverse-proxy service is then performed (no dropped connections, no restart);
• the corresponding journal entries are flagged in the Websites reloaded column.

If reverse-proxy service is not enabled on the appliance, the renewal is stored normally and no reload is attempted.

REST API

The journal is exposed on the local articarest socket (and on the authenticated REST port):

SOCKET="/usr/share/artica-postfix/bin/run/articarest.sock"
# Last renewal events (most recent first)
curl -s --unix-socket $SOCKET "http://localhost/letsencrypt/renewals/logs?limit=100"
# Only failures for one domain
curl -s --unix-socket $SOCKET "http://localhost/letsencrypt/renewals/logs?domain=www.example.com&status=failed"
# Global counters
curl -s --unix-socket $SOCKET "http://localhost/letsencrypt/renewals/stats"

Parameters of /letsencrypt/renewals/logs: 

1. domain (exact CommonName), 
2. status (success or failed), 
3. limit (default 100, maximum 1000). 

Each entry returns: date, common_name, domains, challenge, provider, status, error, duration_ms, new_expiry.

Example answer of /letsencrypt/renewals/stats:

{
  "stats": {
      "total": 6,
      "success": 4,
      "failed": 2,
      "last_success": "2026-08-02 23:31:45",
      "last_failure": "2026-07-29 23:31:45"
  },
  "success": true
}

Notes

• Events are retained for one year; older entries are purged automatically.
• The journal is stored in a dedicated database on the appliance (/home/artica/SQLITE/letsencrypt_renewals.db) — it is not part of the certificates database and can be queried without impacting certificate operations.
• Journaling is best-effort by design: a storage problem never blocks or delays a certificate renewal.
• An empty history simply means no renewal attempt has occurred yet since the feature was installed — certificates are only renewed when they approach expiry.