[{"data":1,"prerenderedAt":193},["ShallowReactive",2],{"seo-verification":3,"blog-short-tls-certificates-automate-with-acme-ma-en":6,"promo-bar-likely":184},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-short-tls-certificates-automate-with-acme-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":139,"ctaBody":140,"ctaButton":141,"ctaUrl":142,"relatedPosts":143},204,"short-tls-certificates-automate-with-acme",{"fr":12,"en":10,"ar":13,"es":14},"certificats-tls-courts-automatiser-acme","شهادات-tls-القصيرة-أتمتة-التجديد-بـ-acme","certificados-tls-cortos-automatizar-con-acme","Short TLS certificates: automate with ACME","Let's Encrypt moves to 64-day certificates on February 10, 2027, then 45 days. Timeline, ARI and a checklist for certbot, acme.sh, Caddy, Traefik, nginx.",12,1,false,"2026-08-01T00:00:00+00:00","2026-10-23T13:27:09+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcertificats-tls-courts-automatiser-acme-poster.svg","The CA\u002FB Forum has decided: the maximum validity of public TLS certificates is coming down in steps, from 398 to 200 days since March 15, 2026, then to 100 days on March 15, 2027 and to 47 days on March 15, 2029. Let's Encrypt is moving faster: its default certificates go from 90 to 64 days on February 10, 2027, then to 45 days on February 16, 2028. A renewal set to run \"every 60 days\" will therefore stop working. This guide covers the timeline, what changes in renewal logic and the checklist for each ACME client.",[35,39,49,52,55,91,94,125,128,136],{"type":36,"title":37,"body":38},"h2","Why certificates are getting shorter","The CA\u002FB Forum, the body that brings together certificate authorities and browser vendors, adopted ballot SC-081v3 in April 2025. It schedules a gradual reduction of two durations: certificate validity and the period during which a domain validation can be reused. Apple, Google, Microsoft and Mozilla all voted in favour. The goal is twofold: limit the exposure of a compromised key or a mis-issued certificate, and force infrastructures to renew often, which means automating. A certificate valid for a year is rarely revoked in time when its key leaks; a six-week certificate expires on its own before it can do much damage. The industry is following: in 2026, AWS Certificate Manager opened an ACME endpoint that issues 45-day public certificates. Shorter lifetimes only reduce the attack surface on one condition: renewal must be reliable, automatic and monitored. That is what this guide sets up.",{"type":40,"title":41,"items":42},"ul","The concrete risks of manual renewal",[43,44,45,46,47,48],"**Silent expiry** — a manually renewed certificate depends on a calendar alert or a human reminder, two mechanisms that regularly fail during busy periods or team changes.","**Late alerts** — classic monitoring tools warn at 30 days before expiry, a threshold designed for one-year certificates; on a 64-day certificate, the alert fires when more than half of its life is already gone.","**No more email reminders** — Let's Encrypt stopped sending its expiration warning emails on June 4, 2025; if nothing monitors your certificates, nobody warns you anymore.","**Frozen cryptographic settings** — manual renewal encourages reusing the same configuration; automation instead enforces a key policy applied every time.","**Impact on service commitments** — an outage caused by an expired certificate engages contractual liability and damages the platform's reputation.","**Growing operational load** — renewing at two thirds of the lifetime, a 64-day certificate renews about eight times a year, and around twelve times at 45 days, with no added value for the team.",{"type":36,"title":50,"body":51},"The CA\u002FB Forum timeline: 200, 100, then 47 days","The Baseline Requirements set the maximum lifetime of a public server certificate, whichever authority issues it. Since March 15, 2026, it has been 200 days, down from 398. On March 15, 2027, it will drop to 100 days. On March 15, 2029, it will reach 47 days. The period during which an authority can reuse a domain validation already performed follows the same slope: 200 days, then 100 days, then only 10 days. This second curve is the least discussed and the most constraining: it means your ACME client will have to prove control of the domain at almost every renewal. If your validation relies on a DNS record added by hand, or on a port 80 that is only open from time to time, this is what will break first. Commercial certificates bought today are already capped at 200 days: the change is not coming, it has started.",{"type":36,"title":53,"body":54},"Let's Encrypt moves to 64 days: the dates that matter","Let's Encrypt announced on October 7, 2026 a schedule faster than the regulatory cap. Since October 14, 2026, its staging environment issues 64-day certificates so you can test. On February 10, 2027, every certificate issued or renewed in production with the default profile, `classic`, will be valid for 64 days, and authorization reuse will drop from 30 to 10 days. The last 90-day certificate is expected to expire around May 11, 2027. On February 16, 2028, the default profile will move to 45 days, with authorization reuse cut to 7 hours. Optional profiles already exist: `tlsserver` issues 45-day certificates, `shortlived` certificates of about six days. Let's Encrypt states that valid certificates will not be revoked, that rate limits do not change and that ACME endpoints and issuance chains stay the same.",{"type":56,"title":57,"headers":58,"rows":62},"comparison","Reference table: what changes, and when",[59,60,61],"Deadline","Change","What you need to check",[63,67,71,75,79,83,87],[64,65,66],"March 15, 2026","CA\u002FB Forum cap at 200 days","Your annual commercial certificates are already capped",[68,69,70],"October 14, 2026","Let's Encrypt staging at 64 days","Your renewal chain passes against staging",[72,73,74],"February 10, 2027","`classic` profile at 64 days, authorizations reusable for 10 days","No delay hard-coded at 60, 80 or 83 days",[76,77,78],"March 15, 2027","CA\u002FB Forum cap at 100 days","Automated renewal with all your authorities",[80,81,82],"May 11, 2027","Expected expiry of the last 90-day Let's Encrypt certificate","No 90-day certificate left in the inventory",[84,85,86],"February 16, 2028","`classic` profile at 45 days, authorizations reusable for 7 hours","Domain validation succeeds at every renewal",[88,89,90],"March 15, 2029","CA\u002FB Forum cap at 47 days, validation reusable for 10 days","Expiry monitoring across the whole fleet",{"type":36,"title":92,"body":93},"What changes in renewal logic","The rule to remember is simple: renew at two thirds of the lifetime, never at a fixed number of days. On 64 days, that means renewing around day 43, with three weeks of margin to fix a failure. A cron job set to \"renew every 60 days\" would leave only four days of margin, and on a 45-day certificate it would run after expiry. Let's Encrypt recommends searching your crontabs, scripts and runbooks for hard-coded values such as 60, 80 or 83. The second lever is called ARI, for ACME Renewal Information, standardised as RFC 9773: the authority itself tells your client a renewal window. If your client supports it, it follows the new lifetimes automatically, and it renews earlier if the authority has to revoke certificates in bulk. This is the setup Let's Encrypt recommends: with ARI enabled, the 64-day announcement requires no action on your part.",{"type":95,"title":96,"steps":97},"steps","Automation checklist, client by client",[98,101,104,107,110,113,116,119,122],{"title":99,"body":100},"Inventory the certificates in place","List every active certificate: covered domains, issuing authority, expiry date, validation method (HTTP-01, DNS-01, TLS-ALPN-01) and the client that renews it. `certbot certificates` lists those managed by certbot. For the others, `echo | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>\u002Fdev\u002Fnull | openssl x509 -noout -issuer -dates` shows the issuer and validity dates. Also note certificates copied by hand to a load balancer, a NAS or a network appliance: those are the ones that expire silently.",{"title":102,"body":103},"Check that your client speaks ARI","certbot supports ARI since version 4.1.0, and `acme.sh` since version 3.1.4, where it is enabled by default. Caddy has included it since version 2.8. Check the installed version with `certbot --version` or `acme.sh --version`. An older distribution may ship an earlier certbot: in that case install the snap package recommended by the EFF, or a dedicated Python environment, rather than keeping a version that ignores the window suggested by the authority.",{"title":105,"body":106},"certbot: remove hard-coded delays","Since version 4.0.0, certbot renews by default when one third of the lifetime remains, and ARI can bring that date forward. Open `\u002Fetc\u002Fletsencrypt\u002Frenewal\u002Fyour-domain.com.conf` and remove a too-short `renew_before_expiry` value inherited from an old tutorial: without it, the one-third rule applies. Check that the scheduler runs with `systemctl list-timers | grep certbot`. To switch to 45 days right now, the `--preferred-profile tlsserver` option requests that profile at issuance.",{"title":108,"body":109},"acme.sh: let ARI decide","Since version 3.1.4, `acme.sh` follows the authority's ARI window and its cron job runs every six hours; `acme.sh --install-cronjob` reinstalls it if it has disappeared. Beware of the opposite trap: since version 3.1.5, an explicit `--days` or `--valid-to` option takes precedence over ARI. An old issuance command with `--days 60` would therefore force a renewal on day 60 of a 64-day certificate. Remove it, then check the next scheduled renewal with `acme.sh --list`.",{"title":111,"body":112},"Caddy: check storage and ports","Caddy handles ACME natively and combines ARI, the actual certificate lifetime and its revocation status to decide when to renew: no configuration is needed to absorb 64 and then 45 days. The two points to check are elsewhere. Caddy's data directory must be persistent, otherwise every container recreation requests certificates again and eventually hits a rate limit. And port 80, or port 443 for TLS-ALPN-01, must stay reachable from the Internet for validation.",{"title":114,"body":115},"Traefik: do not distort certificatesDuration","Traefik schedules renewals from the `certificatesDuration` option, expressed in hours. Its default value, `2160` (90 days), triggers a renewal 30 days before expiry: on a 64-day certificate, that falls around day 34, with a comfortable margin. Do not copy a value found in an old tutorial: according to the documentation, a declared duration between 7 and 30 days only triggers renewal one day before expiry. Finally, keep `acme.json` on a persistent volume, with mode `600`.",{"title":117,"body":118},"nginx: automate the reload","nginx does not reread a renewed certificate until it is reloaded: a successful renewal can therefore leave the old certificate in service until it expires. With certbot, put an executable script containing `nginx -t && systemctl reload nginx` in `\u002Fetc\u002Fletsencrypt\u002Frenewal-hooks\u002Fdeploy\u002F`, or pass `--deploy-hook \"systemctl reload nginx\"` at issuance. With `acme.sh`, the `--reloadcmd \"systemctl reload nginx\"` option of `--install-cert` stores the command for later renewals. NGINX also offers a native ACME module, `ngx_http_acme_module`.",{"title":120,"body":121},"Test against staging","Run your chain against the staging environment, which already issues 64-day certificates and has much higher rate limits. With certbot, `certbot renew --dry-run` goes through staging without touching your certificates; this mode does not query ARI. To get a real test certificate, use `--test-cert` on a non-critical domain. With `acme.sh`, add `--staging`. With Caddy or Traefik, point the authority to `https:\u002F\u002Facme-staging-v02.api.letsencrypt.org\u002Fdirectory`, then check the lifetime with `openssl x509 -noout -dates -in cert.pem`.",{"title":123,"body":124},"Monitor expiry and connect the rest of the fleet","An automated renewal that fails silently is worse than a manual one. Add a deploy hook that notifies an alert channel on every successful renewal, and an independent probe that measures every day the days left on the certificate actually served. Set the alert on a fraction of the lifetime, for example less than a quarter of validity remaining, rather than a fixed 30 days. For the initial setup on a VPS, our guide on SSL certificates with Let's Encrypt covers HTTP-01, DNS-01 and wildcards.",{"type":126,"body":127},"tip","Never assume a renewal setup works until you have seen it work. Several weeks before February 10, 2027, run `certbot renew --force-renewal --cert-name your-domain.com` on a non-critical domain, then check with `openssl s_client` that the server actually serves the new certificate. The test takes a few minutes and removes the most common failure: a certificate renewed on disk that nobody reloaded.",{"type":40,"title":129,"items":130},"Troubleshooting: the most common error messages",[131,132,133,134,135],"**`Timeout during connect (likely firewall problem)`** — the authority could not reach your server on port 80 (HTTP-01) or 443 (TLS-ALPN-01). Check the firewall with `ufw status`, your provider's network rules and the AAAA record: an IPv6 address that is published but not served is enough to make validation fail.","**`Invalid response from http:\u002F\u002Fyour-domain.com\u002F.well-known\u002Facme-challenge\u002F…: 404`** — the challenge file is not served. A misplaced redirect, an overly broad `location` block or a reverse proxy that sends everything to the application is the usual cause; exempt `\u002F.well-known\u002Facme-challenge\u002F` from those rules.","**`CAA record for your-domain.com prevents issuance`** — a DNS CAA record does not authorize this authority. Add `0 issue \"letsencrypt.org\"` to the zone, or the name of the authority you actually use.","**`too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s`** — a script forcing renewal in a loop hit the limit of five identical certificates per week. Wait until the time given after `retry after` and run your tests in staging.","**The browser still shows the old expiry date** — the certificate was renewed on disk, but the web server was not reloaded. Check the deploy hook, then compare `openssl x509 -noout -enddate` on the file and on the live connection.",{"type":36,"title":137,"body":138},"Going further","The move to 64 days is not a one-off event to prepare for: it is one step of a staircase that goes down to 45 days at Let's Encrypt and 47 days at every authority. An infrastructure that renews at two thirds, listens to ARI, reloads its services and monitors the certificate actually served will take every step without intervention. If you are starting with Let's Encrypt on a VPS, our article on SSL certificates with Let's Encrypt covers the initial setup and the special cases of wildcards. For new infrastructures, Caddy deserves particular attention: its native ACME support removes the certificate management layer entirely. Finally, if your validation relies on DNS-01, limit the DNS API token to the single zone concerned: with a validation reusable for only ten days, that token will be used at almost every renewal.","Secure infrastructure, without manual TLS configuration","On ServOrbit VPS, certificate management can be integrated from provisioning. Explore our plans designed for teams who want solid security without unnecessary operational overhead.","See our secure plans","\u002Fpourquoi\u002Fsecurite",[144,160,175],{"id":145,"slug":146,"slugs":147,"title":151,"excerpt":152,"readTime":23,"views":153,"isPinned":19,"noindex":19,"publishedAt":154,"updatedAt":155,"category":156,"categories":157,"featuredImage":30,"bgImage":31,"posterImage":159,"relatedSolution":30},116,"free-ssl-certificates-with-lets-encrypt-on-a-vps",{"fr":148,"en":146,"ar":149,"es":150},"certificats-ssl-lets-encrypt-vps","شهادات-ssl-مجانية-باستخدام-lets-encrypt-على-خادم-vps","certificados-ssl-gratis-con-lets-encrypt-en-un-vps","Free SSL Certificates with Let's Encrypt on a VPS","Complete Let's Encrypt guide for VPS: certbot nginx, DNS-01 wildcard, systemd renewal, TLS hardening, rate-limit troubleshooting and certbot vs acme.sh vs Caddy.",0,"2026-02-24T00:00:00+00:00","2026-09-30T11:20:34+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[158],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fcertificats-ssl-lets-encrypt-vps-poster.svg",{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":153,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":170,"category":171,"categories":172,"featuredImage":30,"bgImage":31,"posterImage":174,"relatedSolution":30},201,"ai-crawlers-taking-back-control-over-your-clients-sites",{"fr":164,"en":162,"ar":165,"es":166},"crawlers-ia-search-training-agent","زواحف-الذكاء-الاصطناعي-استعادة-السيطرة-على-مواقع-عملائكم","crawlers-de-ia-proteger-los-sitios-de-clientes","AI Crawlers: taking back control over your clients' sites","Cloudflare now splits AI crawlers into three families. How to configure robots.txt and Cloudflare rules to protect your clients' sites.",4,"2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[173],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fcrawlers-ia-search-training-agent-poster.svg",{"id":176,"slug":177,"slugs":178,"title":182,"excerpt":183,"readTime":169,"views":153,"isPinned":19,"noindex":184,"publishedAt":20,"updatedAt":170,"category":185,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":30},199,"spf-dkim-dmarc-passing-the-5000-email-threshold",{"fr":179,"en":177,"ar":180,"es":181},"spf-dkim-dmarc-delivrabilite-emails-pro","spf-وdkim-وdmarc-تجاوز-عتبة-5000-رسالة","spf-dkim-dmarc-superar-el-umbral-de-5000-correos","SPF, DKIM, DMARC: passing the 5,000-email threshold","Gmail and Outlook reject senders without aligned SPF, DKIM and DMARC with an SMTP 550 error. Here is how to configure all three records.",true,{"id":186,"name":187,"slug":188,"color":189,"icon":188},11,"Business Email","emails","bg-cyan-500\u002F10 text-cyan-400",[191],{"id":186,"name":187,"slug":188,"color":189,"icon":188},"\u002Fblog\u002Fcovers\u002Fspf-dkim-dmarc-delivrabilite-emails-pro-poster.svg",1794270503292]