2026年11月12日

2026年11月12日

Renew a WordPress Site’s SSL Certificate: Expiry, certbot, Paid Certs

This article is a localized edition of the Japanese original. Read the Japanese original

When an SSL certificate expires, browsers show a warning such as "Your connection is not private", and most visitors cannot open the page. Chrome shows the error code NET::ERR_CERT_DATE_INVALID. This article explains how to check your WordPress site's certificate expiry and renew it based on how it is managed. The information is current as of October 2026.

Changes to know about in 2026

The rules around certificate renewal have changed a lot in the past few years.

Change Details
Let's Encrypt ended expiration notice emails Sending ended on June 4, 2025. You can no longer rely on email notices
Shorter maximum lifetime for public certificates (CA/Browser Forum) Certificates issued on or after March 15, 2026 last at most 200 days. Planned: 100 days from March 15, 2027 and 47 days from March 15, 2029
Shorter Let's Encrypt lifetimes The current default is 90 days. Planned: 64 days from February 10, 2027 and 45 days from February 16, 2028

Even if you bought a paid certificate on a multi-year contract, the certificate itself must be reissued and replaced within 200 days. Manual renewal will happen more often, so automate renewal wherever you can and set up your own expiry monitoring.

Step 1: Check the certificate expiry

In a browser, open the certificate details from the icon at the left of the address bar to see the expiry date and the issuer (certificate authority).

To check from the command line, run the following. Without -servername, a server hosting several sites may return another site's certificate.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -issuer -subject

notAfter= is the expiry date (GMT) and issuer= is the issuer.

Step 2: Find out who manages the certificate

How you renew depends on who issues and manages the certificate.

How it is managed How to tell How to renew
Free SSL from your hosting company You enabled SSL in the hosting control panel. The issuer is often Let's Encrypt or similar The host renews it automatically. Check the control panel for failures (Step 3)
A CDN certificate (Cloudflare or similar) Your DNS points to the CDN. The issuer is a certificate authority the CDN uses Visitors see the CDN's certificate. Check it in the CDN dashboard
certbot on a VPS You obtained it yourself by running certbot Renew with certbot renew. Check that automatic renewal runs (Step 4)
A paid certificate Bought from a reseller or certificate authority Request a reissue (renewal) before expiry and replace it on the server (Step 5)

If you use a CDN, some setups also use the server's own certificate for traffic between the CDN and your server. Check the expiry of the server-side certificate in the CDN dashboard as well.

Step 3: Free SSL from your hosting company

Your hosting company normally renews free SSL automatically. If it is about to expire and has not been renewed, the usual causes are:

  • The domain's DNS (A record) does not point to that server. This happens after moving servers or pointing DNS to a CDN
  • The domain registration has expired, or the DNS settings are gone
  • .htaccess blocks access to the files the certificate authority reads to verify the domain (under /.well-known/acme-challenge/)

Check the certificate status in the SSL settings of your hosting control panel and fix whatever error it shows. If you cannot find the cause, contact your hosting company's support.

Step 4: Using certbot on a VPS

List certificates and their expiry

sudo certbot certificates

For each certificate it shows the name (Certificate Name), the domains, the expiry date (Expiry Date) and the days remaining.

Test the renewal, then renew

# Test only the renewal steps without touching the live certificate
sudo certbot renew --dry-run

# Renew certificates that are close to expiry
sudo certbot renew

certbot renew renews only certificates that are due. From Certbot 4.0 on, a certificate is due when less than one third of its lifetime remains (about 30 days for a 90-day certificate). Before that, the rule was a fixed 30 days. Certificates that are not due are left alone, so running it several times a day is fine.

--force-renewal renews early, but Let's Encrypt allows at most 5 certificates for the same set of domains every 7 days. Repeated attempts can block issuance, so use --dry-run when testing.

Check that automatic renewal runs

Depending on how certbot was installed, it renews automatically with a systemd timer or cron.

# certbot timers with next and last run times
systemctl list-timers | grep -i certbot

# if it runs from cron
grep -r certbot /etc/crontab /etc/cron.d/ 2>/dev/null

If neither shows anything, automatic renewal is not running. Check how certbot was installed, then reinstall it following the official certbot instructions or register certbot renew -q in cron.

When renewal fails

Detailed reasons for failures are written to /var/log/letsencrypt/letsencrypt.log.

sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log

Common causes with the HTTP validation method (HTTP-01):

  • Port 80 is closed by a firewall or a cloud security group
  • The domain's DNS points to a different server
  • The web server configuration blocks access to /.well-known/acme-challenge/

Wildcard certificates (*.example.com) can only be obtained with the DNS TXT record method (DNS-01). A certificate obtained by hand with --manual cannot renew automatically, so either switch to the certbot DNS plugin for your DNS provider or obtain it again by hand before it expires.

Reload the web server after renewal

Even after the certificate files are replaced, the web server keeps using the old certificate until it reloads. Executables placed in /etc/letsencrypt/renewal-hooks/deploy/ run only when a certificate is renewed successfully.

# Nginx example (for Apache use systemctl reload apache2)
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh

Step 5: Replacing a paid certificate

For a paid certificate, request a renewal (reissue) from the reseller or certificate authority before it expires, then install the new certificate on the server.

Create a CSR

If the request needs a CSR (certificate signing request), create it on the server together with the private key.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Paste the contents of example.com.csr into the request form. Keep example.com.key (the private key) on the server with permissions that other users cannot read. On shared hosting, you can often create the CSR in the control panel, so follow its instructions.

Install the issued certificate

Once the certificate authority has verified the domain (by email, a DNS TXT record or a placed file), the certificate is issued. Prepare a file with the server certificate and the intermediate certificate joined together, and point the web server configuration to it.

# Nginx example
ssl_certificate     /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/example.com.key;
# Apache 2.4.8 or later (point to the file that includes the intermediate certificate)
SSLCertificateFile    /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/example.com.key

Before reloading, check that the certificate and private key belong together. If the two values match, they are a pair.

openssl x509 -noout -pubkey -in /etc/ssl/example.com/fullchain.pem | openssl sha256
openssl pkey -pubout -in /etc/ssl/example.com/example.com.key | openssl sha256

Test the configuration, then reload.

# Nginx
sudo nginx -t && sudo systemctl reload nginx

# Apache
sudo apachectl configtest && sudo systemctl reload apache2

If the intermediate certificate is missing, the site may load in desktop browsers but fail on smartphones or from external services.

Step 6: Confirm the renewal

Run the command from Step 1 again and check that notAfter= shows the new date. Browsers can keep showing old certificate information, so also check in another browser or a private window.

On the WordPress side, you do not need to change any settings after renewing the certificate. Certificate errors when WordPress connects to other sites (plugin updates or external APIs), however, are a separate problem from your own site's certificate. For those, see the related articles.

Monitor expiry yourself

Since Let's Encrypt no longer sends notice emails, set up your own expiry monitoring. You can run the command from Step 1 daily with cron to check the days remaining, or use an external monitoring service. For detailed steps, see How to monitor your WordPress site's SSL certificate expiry and send alerts.

Summary

  • Check expiry with openssl s_client plus -servername. The issuer hints at who manages the certificate
  • If free SSL from your host is not renewing, check where DNS points and what the control panel shows
  • With certbot, test with certbot renew --dry-run and then run certbot renew. Check automatic renewal with systemctl list-timers and reload the web server with a deploy hook
  • --force-renewal easily runs into Let's Encrypt issuance limits, so use --dry-run when testing
  • Paid certificates issued from March 2026 last at most 200 days. Even multi-year contracts need reissuing and replacing
  • Let's Encrypt notice emails have ended, so set up your own expiry monitoring

Related articles:

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)

お気軽にご相談ください

お見積りへ お問い合わせへ
▲