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
.htaccessblocks 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_clientplus-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-runand then runcertbot renew. Check automatic renewal withsystemctl list-timersand reload the web server with a deploy hook --force-renewaleasily runs into Let's Encrypt issuance limits, so use--dry-runwhen 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:
- How to set up and check automatic Let's Encrypt renewal (certbot)
- How to monitor your WordPress site's SSL certificate expiry and send alerts
- Fixing the WordPress "certificate has expired" error: your site's certificate vs. outgoing connections
- Fixing WordPress SSL certificate errors: ERR_CERT causes and cURL error 60
Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)