How to monitor SSL certificate expiration for WordPress sites

Write down the exact hostnames visitors use, including example.com, www.example.com, staging domains, shop subdomains, and any separate mail or API hostnames. A certificate can be valid for one hostname while missing another.

Check the public endpoint, not only the certificate file stored on the server. If HTTPS ends at a CDN, load balancer, or hosting proxy, that service may be the one serving the certificate. Conflicting SSL or redirect settings between WordPress, the host, a CDN, DNS proxy, Nginx, or Apache are common causes of failure.

Open each HTTPS address in a browser, select the padlock or connection information, and view the certificate details. Record the expiration date, issuer, subject, and the hostnames covered by the certificate.

For a server-side check, use OpenSSL from a terminal: openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -dates -issuer -subject. The -servername option matters when several sites share one server, and OpenSSL can display the certificate start and expiry dates.

For one or two sites, a spreadsheet and a recurring calendar reminder can be enough. Record each hostname, expiry date, renewal method, responsible person, and a reminder at least 30 days before expiry. Also keep a second reminder several days before the certificate expires.

This route is cheap and does not require a WordPress plugin, but it depends on someone checking the calendar. It is easy to miss a newly added subdomain, a certificate replaced by the host, or a renewal that succeeded on the server but was never deployed to the public endpoint.

In your hosting panel, check that automatic SSL renewal is enabled and that the domain still passes its validation checks. On a server using Certbot, certbot certificates lists managed certificates, while certbot renew --dry-run tests whether a future renewal can complete without saving a live certificate. Certbot renewals normally reuse the existing configuration and may need a scheduled task or systemd timer.

Do not treat automatic renewal as proof that monitoring is working. After renewal, confirm that the certificate presented at the public hostname has the new expiry date. Pay particular attention after changing DNS, moving hosts, changing web servers, or putting a CDN in front of the site.

Visit the homepage, the WordPress login page, and important forms over HTTPS. Confirm that HTTP redirects to HTTPS, the certificate matches the hostname, and browsers show no certificate warning.

Check the browser console or page source for HTTP assets. Mixed content means a page served over HTTPS is requesting resources over HTTP; it can remove the secure indicator even when the certificate itself is valid. Fix the source URL, CDN setting, or WordPress content rather than assuming the certificate is at fault.

If you manage several WordPress sites, the fast route is a central SSL monitor that checks the certificates served by each connected site and emails you before a chosen threshold. This avoids maintaining separate calendar reminders and gives you one list to review after hosting or DNS changes.

If you already use MainWP, the MainWP SSL Monitor Extension is a suitable option. In the MainWP Dashboard, install and activate it from MainWP > Extensions, then open its SSL Monitor settings, set the notification threshold, and enable automated checks. You can check all connected sites, inspect individual certificate details, and override the global settings for a particular site.