{"id":2918,"date":"2026-10-29T09:28:36","date_gmt":"2026-10-29T09:28:36","guid":{"rendered":"https:\/\/hostry.com\/blog\/?p=2918"},"modified":"2026-10-29T09:28:37","modified_gmt":"2026-10-29T09:28:37","slug":"lets-encrypt-45-day-certificates","status":"publish","type":"post","link":"https:\/\/hostry.com\/blog\/lets-encrypt-45-day-certificates\/","title":{"rendered":"Let&#8217;s Encrypt 45-Day Certificates: Automate Renewal Before 2027"},"content":{"rendered":"\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"892\" height=\"508\" src=\"https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-a_main.png\" alt=\"Let's Encrypt 45-day certificates: automated renewal on a Linux VPS\" class=\"wp-image-2915\" srcset=\"https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-a_main.png 892w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-a_main-300x171.png 300w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-a_main-450x256.png 450w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-a_main-768x437.png 768w\" sizes=\"auto, (max-width: 892px) 100vw, 892px\" \/><\/figure>\n\n\n\n<pre class=\"wp-block-preformatted\" style=\"font-size:14px\"><em><strong>Let's Encrypt cuts its default certificate lifetime from 90 to 64 days on February 10, 2027, and to 45 days on February 16, 2028. If certbot or acme.sh already renews on its own, test it and add an expiry alert. Manual renewals, fixed 60-day cron jobs and certificates copied to other machines need fixing now.<\/strong><\/em><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">You do not have to wait for 2028 to see how your servers handle <strong>Let&#8217;s Encrypt 45-day certificates<\/strong>: an opt-in profile has issued them since May 13, 2026, and the staging environment has issued 64-day certificates since October 14, 2026. On <strong><a href=\"https:\/\/hostry.com\/products\/hosting\/\">cPanel web hosting<\/a><\/strong> with free automatic SSL, the panel handles renewal and you have nothing to change.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">When Let&#8217;s Encrypt 45-day certificates become the default<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt announced the schedule in <strong><a href=\"https:\/\/letsencrypt.org\/2025\/12\/02\/from-90-to-45.html\" target=\"_blank\" rel=\"noopener\">its December 2025 post on moving from 90 to 45 days<\/a><\/strong>. The change runs through ACME profiles: <span class=\"highlighted\">classic<\/span> is what every client gets unless it asks for something else, and <span class=\"highlighted\">tlsserver<\/span> is the opt-in profile for early adopters.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Date<\/th><th>Profile<\/th><th>Certificate lifetime<\/th><th>Authorization reuse<\/th><\/tr><\/thead><tbody><tr><td>Until February 9, 2027<\/td><td>classic (default)<\/td><td>90 days<\/td><td>30 days<\/td><\/tr><tr><td>Since May 13, 2026<\/td><td>tlsserver (opt-in)<\/td><td>45 days<\/td><td>7 hours<\/td><\/tr><tr><td>February 10, 2027<\/td><td>classic (default)<\/td><td>64 days<\/td><td>10 days<\/td><\/tr><tr><td>February 16, 2028<\/td><td>classic (default)<\/td><td>45 days<\/td><td>7 hours<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Authorization reuse shrinks too, and that matters as much as the lifetime: today a client can often renew on a validation done weeks earlier. At 7 hours, almost every renewal has to pass a fresh HTTP-01 or DNS-01 challenge, so a broken validation path shows up at the next renewal instead of hiding behind an old authorization.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The new lifetimes apply to newly issued certificates, so you meet each one at your first renewal after the date. Existing certificates are not revoked. According to the <strong><a href=\"https:\/\/letsencrypt.org\/2026\/10\/07\/64-day-certs\" target=\"_blank\" rel=\"noopener\">Let&#8217;s Encrypt announcement of 64-day certificates<\/a><\/strong>, the last 90-day certificate should expire around May 11, 2027.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong><a href=\"https:\/\/cabforum.org\/2025\/04\/11\/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods\/\" target=\"_blank\" rel=\"noopener\">CA\/Browser Forum ballot SC-081v3<\/a><\/strong>, passed in April 2025, reduces the maximum validity of every publicly trusted TLS certificate from 398 days to 47 days in steps between March 2026 and March 2029, so a <strong>shorter SSL certificate lifetime<\/strong> reaches paid certificates too.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Who needs to do something?<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>cPanel hosting customers<\/strong>: nothing. Hostry cPanel hosting includes free automatic Let&#8217;s Encrypt SSL, and you do not run certbot yourself.<\/li><li>On a VPS where certbot or acme.sh runs on its default schedule, check the client version, run a dry run and confirm the web server reloads after renewal.<\/li><li>Manual renewals, custom cron jobs, certificates copied to other machines and DNS-01 with hand-typed TXT records fail first, so fix them before February 10, 2027.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">How to check Certbot and acme.sh renewal on a VPS<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Log in over SSH and work through the four checks in order. Replace <span class=\"highlighted\">example.com<\/span> with your own domain in every command.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\" style=\"font-size:14px\"><strong>1. Find the client and its version<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>certbot --version\nsnap list certbot\nls -d ~\/.acme.sh 2&gt;\/dev\/null &amp;&amp; ~\/.acme.sh\/acme.sh --version<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong><a href=\"https:\/\/eff-certbot.readthedocs.io\/en\/stable\/using.html\" target=\"_blank\" rel=\"noopener\">Certbot user guide<\/a><\/strong> and changelog record three changes that matter here. Certbot 4.0 added the <span class=\"highlighted\">&#8211;preferred-profile<\/span> and <span class=\"highlighted\">&#8211;required-profile<\/span> flags. The same release moved renewal to the point where one third of the lifetime remains. Certbot 4.1 added <strong>ACME Renewal Information (ARI)<\/strong>, which lets Let&#8217;s Encrypt tell the client when to renew.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ubuntu 24.04 ships certbot 2.9.0 in its apt repository. That version renews 30 days before expiry, which still works for 64- and 45-day certificates, but it cannot follow ARI or request a profile. The snap tracks current releases, which is a good reason to prefer it on Ubuntu.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For <strong>acme.sh renewal<\/strong>, version 3.1.2 added certificate profiles, and 3.1.4 turned on ARI by default and moved the installed cron job to every 6 hours. Builds older than 3.1.3 schedule renewal 60 days after issuance by default, which leaves about five days on a 64-day certificate and comes after a 45-day one has expired, so run <span class=\"highlighted\">acme.sh &#8211;upgrade<\/span> on anything older. Also note that acme.sh uses ZeroSSL unless you chose Let&#8217;s Encrypt; the CA column in <span class=\"highlighted\">acme.sh &#8211;list<\/span> shows which one issued each certificate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\" style=\"font-size:14px\"><strong>2. Find what triggers renewal<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl list-timers | grep -i certbot\ncrontab -l | grep -i -E \"certbot|acme\"\ngrep -rn -E \"certbot|acme\" \/etc\/crontab \/etc\/cron.d\/ 2&gt;\/dev\/null<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">An apt install normally shows <span class=\"highlighted\">certbot.timer<\/span>, a snap install shows <span class=\"highlighted\">snap.certbot.renew.timer<\/span>, and acme.sh adds a line with <span class=\"highlighted\">acme.sh &#8211;cron<\/span> to the crontab of the user who installed it. The apt package also ships <span class=\"highlighted\">\/etc\/cron.d\/certbot<\/span>, but that entry skips itself on systemd hosts, so it is not a second scheduler. Two schedulers for the same certificates, or none, both need fixing.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\" style=\"font-size:14px\"><strong>3. Run a dry run<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo certbot certificates\nsudo certbot renew --dry-run\nacme.sh --list<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">With certbot, <span class=\"highlighted\">certbot certificates<\/span> lists each certificate with its expiry date and days left. The dry run requests staging certificates without saving them, so every lineage passes a real challenge. Since staging already issues 64-day certificates, a clean dry run today also tests the lifetime arriving in February.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">acme.sh has no dry-run mode, so use the staging test further down to exercise it end to end. After a real renewal, the dates in <span class=\"highlighted\">acme.sh &#8211;list<\/span> and <span class=\"highlighted\">Le_NextRenewTime<\/span> in the certificate&#8217;s <span class=\"highlighted\">.conf<\/span> file move forward. With <span class=\"highlighted\">&#8211;log<\/span> enabled, a root install logs to <span class=\"highlighted\">\/root\/.acme.sh\/acme.sh.log<\/span>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\" style=\"font-size:14px\"><strong>4. Compare the file with what visitors get<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo openssl x509 -enddate -noout -in \/etc\/letsencrypt\/live\/example.com\/cert.pem\necho | openssl s_client -connect example.com:443 -servername example.com 2&gt;\/dev\/null | openssl x509 -noout -dates<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If the expiry date visitors get is older than the expiry date of the file on disk, the web server is still serving the previous certificate. That points straight at a missing reload, covered in the next section.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fix what breaks first<\/h2>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"800\" src=\"https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain.png\" alt=\"Let's Encrypt renewal flow on a VPS: timer, ACME client, challenge, certificate files, deploy hook and service reload, with common failure points\" class=\"wp-image-2917\" srcset=\"https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain.png 1200w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain-300x200.png 300w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain-1024x683.png 1024w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain-450x300.png 450w, https:\/\/hostry.com\/blog\/wp-content\/uploads\/2026\/10\/le45-renewal-chain-768x512.png 768w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><figcaption>Each step of an automated renewal, and the setups that break it once lifetimes get shorter<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Fixed intervals and monthly jobs<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt says a hardcoded 60-day renewal interval will no longer be enough, and its 64-day post suggests searching cron jobs, shell scripts and runbooks for values such as 83, 80 or 60. The rule of thumb for clients without ARI is to renew at about <strong>two thirds of the certificate&#8217;s lifetime<\/strong>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep -rn renew_before_expiry \/etc\/letsencrypt\/renewal\/\ngrep -rn Le_RenewalDays ~\/.acme.sh\/*\/*.conf 2&gt;\/dev\/null\ngrep -rn -E \"days|60|80|83\" \/etc\/cron.d\/ \/usr\/local\/bin\/ 2&gt;\/dev\/null | grep -i -E \"cert|acme|ssl\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">In acme.sh, a <span class=\"highlighted\">Le_RenewalDays<\/span> line means the certificate was issued with a fixed <span class=\"highlighted\">&#8211;days<\/span> value, and since 3.1.5 that value takes priority over ARI. Watch out for cron jobs that run <span class=\"highlighted\">certbot renew<\/span> once a month. A 45-day certificate becomes due around day 30. If the job runs on day 28 the certificate is not due yet, and the next run on day 58 comes after it has expired. Delete the custom job and let the packaged timer run, since it checks twice a day.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">No reload after renewal<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When certbot uses the nginx or Apache installer plugin, it reloads the server itself. With <span class=\"highlighted\">certonly<\/span>, webroot or standalone, nobody does unless you add a deploy hook. Scripts in <span class=\"highlighted\">\/etc\/letsencrypt\/renewal-hooks\/deploy\/<\/span> run after every successful renewal:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo tee \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-web.sh &gt;\/dev\/null &lt;&lt;'EOF'\n#!\/bin\/sh\nsystemctl reload nginx\nEOF\nsudo chmod +x \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-web.sh\nsudo certbot renew --dry-run --run-deploy-hooks<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Use <span class=\"highlighted\">systemctl reload apache2<\/span> on Debian or Ubuntu with Apache. A plain dry run skips deploy hooks. <span class=\"highlighted\">&#8211;run-deploy-hooks<\/span>, available since certbot 2.3 and so also in the 2.9.0 apt package, runs them against the current certificate once the dry run succeeds. With acme.sh, the reload lives in the <span class=\"highlighted\">&#8211;install-cert<\/span> step:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>acme.sh --install-cert -d example.com \\\n  --key-file \/etc\/nginx\/ssl\/example.com.key \\\n  --fullchain-file \/etc\/nginx\/ssl\/example.com.fullchain.pem \\\n  --reloadcmd \"systemctl reload nginx\"<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Certificates copied to other services<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Mail servers such as Postfix and Dovecot often read the same files from <span class=\"highlighted\">\/etc\/letsencrypt\/live\/<\/span> and need a reload to pick up a renewed certificate reliably. Certbot sets <span class=\"highlighted\">$RENEWED_LINEAGE<\/span> for deploy hooks, so one hook can react to a specific certificate:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>#!\/bin\/sh\n# \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-mail.sh\ncase \"$RENEWED_LINEAGE\" in\n  *\/mail.example.com) systemctl reload postfix dovecot ;;\nesac<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Load balancers, NAS boxes and appliances that get a certificate uploaded by hand are harder. At two thirds of the lifetime, a 64-day certificate means an upload roughly every six weeks and a 45-day one every 30 days. Where the device has an API, push the certificate from a deploy hook. Where it can run its own ACME client, let it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When a device has no API and cannot run any ACME client, the <strong><a href=\"https:\/\/hostry.com\/solutions\/ssl-for-free\/\">free SSL certificate generator<\/a><\/strong> is a manual exception, not a renewal solution: it issues Let&#8217;s Encrypt certificates in the browser, with up to 100 names per certificate and your own CSR if you need one. Add every such certificate to the expiry check below and plan uploads at the cadence above.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Port 80 closed for HTTP-01<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The HTTP-01 challenge can only be done on port 80. If someone closed port 80 after the first issuance, or opens it by hand before each renewal, renewals fail. If you followed our checklist to <strong><a href=\"https:\/\/hostry.com\/blog\/secure-new-linux-vps-first-30-minutes\/\">secure a new Linux VPS<\/a><\/strong>, the UFW rule for <span class=\"highlighted\">80,443\/tcp<\/span> already covers this. Also check the firewall in your provider&#8217;s control panel. You can keep port 80 as a redirect to HTTPS, because the challenge follows redirects.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">DNS-01 with hand-edited TXT records<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Wildcard certificates need DNS-01. If you issued one with certbot&#8217;s <span class=\"highlighted\">&#8211;manual<\/span> mode and pasted the TXT record into a DNS panel, <span class=\"highlighted\">certbot renew<\/span> cannot renew it without an auth hook. Switch to a DNS plugin for certbot, or one of the DNS API integrations in acme.sh, which need an API token from your DNS provider. Limit that token to DNS edits on only the zones you need certificates for, and make certbot&#8217;s credentials file readable only by its owner with <span class=\"highlighted\">chmod 600<\/span>; the certbot-dns-cloudflare docs give the same advice.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt&#8217;s planned <strong>DNS-PERSIST-01<\/strong> challenge uses a static TXT record you set once. It was expected in 2026, but as of late October 2026 Let&#8217;s Encrypt had not announced production availability, so do not plan around it yet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Test 45-day certificates now<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Both the staging and production ACME directories already list the <span class=\"highlighted\">tlsserver<\/span> profile, so you can try Let&#8217;s Encrypt 45-day certificates today. The safest first test uses staging and a throwaway name such as <span class=\"highlighted\">test.example.com<\/span> that already points at the server:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo certbot certonly --staging --nginx -d test.example.com --required-profile tlsserver\nsudo openssl x509 -noout -dates -in \/etc\/letsencrypt\/live\/test.example.com\/cert.pem\nsudo certbot delete --cert-name test.example.com<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Use <span class=\"highlighted\">&#8211;required-profile<\/span> for the test: <span class=\"highlighted\">&#8211;preferred-profile<\/span> quietly falls back to the default if the profile is unavailable, while the required form fails, so you know what you got. The dates should be 45 days apart. With acme.sh 3.1.2 or later, the equivalent is <span class=\"highlighted\">acme.sh &#8211;issue &#8211;staging -d test.example.com -w \/var\/www\/html &#8211;cert-profile tlsserver<\/span>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">To move a production site to 45 days, re-issue it with the command you originally used plus <span class=\"highlighted\">&#8211;preferred-profile tlsserver &#8211;force-renewal<\/span>. Certbot 4.1 and later stores the profile in <span class=\"highlighted\">\/etc\/letsencrypt\/renewal\/example.com.conf<\/span>, so later renewals keep it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Do not opt in everywhere: a <span class=\"highlighted\">tlsserver<\/span> certificate holds at most 25 names and has no Common Name, which matters if anything in your stack still reads the CN. Leave certificates you still copy by hand on <span class=\"highlighted\">classic<\/span> until that copy is automated.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">SSL certificate expiry monitoring that catches failed renewals<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt recommends monitoring alongside automation. Check the certificate each service actually serves, which also catches the &#8220;renewed but not reloaded&#8221; case:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo tee \/usr\/local\/bin\/check-cert-expiry.sh &gt;\/dev\/null &lt;&lt;'EOF'\n#!\/bin\/sh\nDAYS=10\nfor target in example.com:443 www.example.com:443 mail.example.com:993; do\n  host=${target%:*}\n  if ! echo | openssl s_client -connect \"$target\" -servername \"$host\" 2&gt;\/dev\/null \\\n       | openssl x509 -noout -checkend $((DAYS * 86400)) &gt;\/dev\/null 2&gt;&amp;1; then\n    echo \"Certificate on $target expires within $DAYS days or could not be read\" \\\n      | mail -s \"TLS certificate alert: $target\" admin@example.com\n  fi\ndone\nEOF\nsudo chmod +x \/usr\/local\/bin\/check-cert-expiry.sh\necho \"17 7 * * * root \/usr\/local\/bin\/check-cert-expiry.sh\" | sudo tee \/etc\/cron.d\/cert-expiry<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Replace the targets and the address with your own. The <span class=\"highlighted\">mail<\/span> command needs a local mail setup such as the <span class=\"highlighted\">mailutils<\/span> package, or you can swap that line for a call to your chat or alerting webhook. To prove the alert path works, set <span class=\"highlighted\">DAYS=90<\/span> in the script for a moment, run it by hand, confirm the message arrives, then set it back to 10.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Why 10 days?<\/strong> A client renewing at two thirds of the lifetime starts trying with about 21 days left on a 64-day certificate and 15 days on a 45-day one. An alert at 10 days stays quiet while normal retries run, then leaves you a week and a half to fix the problem. The 30-day thresholds many people set for 90-day certificates would fire on every healthy 45-day certificate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A check on the same server shares its failures: if the VPS is down or cron is broken, nothing reports. Add at least one outside view of the expiry date:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>An uptime monitoring service that also checks certificate expiry.<\/li><li>The same script running from a second machine, pointed at your public hostnames.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">A <strong>Certificate Transparency monitor<\/strong> adds a separate signal: it shows what CAs issued for your domains, including certificates you did not request, while the served-certificate check shows what your services present. A new CT entry with no change on the server means a renewal never got deployed.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Renewal timing at a glance<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The margin for a failed renewal shrinks with every step. Figures assume renewal at two thirds of the lifetime and a 10-day alert:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Lifetime<\/th><th>Default for<\/th><th>Renewal starts around<\/th><th>Days left at that point<\/th><th>Days of failed retries before the alert<\/th><\/tr><\/thead><tbody><tr><td>90 days<\/td><td>Certificates issued until February 9, 2027<\/td><td>Day 60<\/td><td>30<\/td><td>20<\/td><\/tr><tr><td>64 days<\/td><td>Certificates issued from February 10, 2027<\/td><td>Day 43<\/td><td>21<\/td><td>11<\/td><\/tr><tr><td>45 days<\/td><td>tlsserver now; default from February 16, 2028<\/td><td>Day 30<\/td><td>15<\/td><td>5<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">What to do next<\/h2>\n\n\n\n<ol class=\"wp-block-list\"><li>Set a reminder for the week after February 10, 2027 to confirm that every server has picked up a 64-day certificate, and another after February 16, 2028.<\/li><li><strong>Add the expiry check to your server build notes<\/strong>, so a new site or mail host is monitored from its first certificate.<\/li><li>Inventory every certificate that is copied off the server where it renews, such as to a mail server, a load balancer or an appliance, and note for each one how the renewed file gets there.<\/li><\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Why is Let&#8217;s Encrypt shortening certificate lifetimes?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The CA\/Browser Forum Baseline Requirements now demand it. Let&#8217;s Encrypt also points to two security benefits: a shorter lifetime limits how long a compromised certificate can be misused, and it makes revocation technologies more efficient.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Will I hit rate limits by renewing more often?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt says rate limits will not be impacted by this change. Renewals of the same set of names are exempt from the per-domain and per-account limits, and renewals timed by ARI are exempt from all of them, so the higher renewal frequency of 64- and 45-day certificates does not count against you.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can I keep 90-day certificates?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Not from Let&#8217;s Encrypt. The default profile itself moves to 64 days on February 10, 2027, and the opt-in profiles are shorter, not longer. Paid certificates will not help for long either, because the CA\/Browser Forum limits apply to every public CA.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do I need to change my web server configuration?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Usually not. Nginx or Apache keeps reading the same files under <span class=\"highlighted\">\/etc\/letsencrypt\/live\/<\/span>, and Let&#8217;s Encrypt 45-day certificates only replace them more often. Whether the server reloads after each replacement depends on the installer-plugin and deploy-hook cases described under &#8220;No reload after renewal&#8221;.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Setting up a new server for your sites?<\/strong> A <strong><a href=\"https:\/\/hostry.com\/products\/vps\/\">Hostry KVM VPS<\/a><\/strong> gives you full root access in 18+ locations and is ready in seconds. Renewal setup and testing on it stay with you as the server owner.<\/p>\n<!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p>Let&#8217;s Encrypt moves to 64-day certificates in February 2027 and 45-day ones in February 2028. Here is how to audit certbot or acme.sh renewal on a VPS&#8230;<\/p>\n","protected":false},"author":6,"featured_media":2916,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,127],"tags":[],"class_list":["post-2918","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-servers","category-security"],"read_time":9,"_links":{"self":[{"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/posts\/2918","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/comments?post=2918"}],"version-history":[{"count":1,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/posts\/2918\/revisions"}],"predecessor-version":[{"id":2925,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/posts\/2918\/revisions\/2925"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/media\/2916"}],"wp:attachment":[{"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/media?parent=2918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/categories?post=2918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hostry.com\/blog\/wp-json\/wp\/v2\/tags?post=2918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}