MainWP SSL Monitor - WordPress Plugin

Guide to Configuring and Using MainWP SSL Monitor

MainWP SSL Monitor is not meant to replace proper SSL certificate issuance and renewal at the hosting level. Its job is to continuously monitor certificates across connected WordPress sites from a single MainWP Dashboard. In this guide, we will walk through how to prepare the Dashboard and Child site setup, where to enable checks, how to set a sensible notification threshold, when to use manual checks, and how to read the results in the certificate table.

This article is written for an agency owner, a multi-site administrator, or a developer who already uses MainWP or is just setting up a separate Dashboard to maintain client projects. We will not repeat the plugin's marketing copy. Instead, we will go from installation to a practical workflow: choose a reasonable notification threshold, check all sites, investigate one problematic domain, disable monitoring where it is not needed, and avoid confusing a certificate issue with a general MainWP connection problem.

The product has a narrow but important responsibility: make sure an HTTPS certificate never expires unnoticed. That means the value of MainWP SSL Monitor is not in the number of buttons it offers, but in how disciplined your monitoring process is: which sites you track, how often automated checks run, who receives the emails, where to review certificate details, and what to do if the status suddenly changes after a domain migration, CDN swap, or SSL renewal at the hosting provider.

What Problem SSL Monitoring Solves in MainWP

For a single site, certificate checks are usually done manually: an administrator opens the site in a browser, looks for the lock icon in the address bar, and sometimes checks the hosting panel. That approach falls apart quickly when you are dealing with ten, fifty, or a hundred client sites. Different domains may be on different hosts, use different certificate authorities, renew on different schedules, and sit behind different CDN proxy setups. MainWP SSL Monitor brings all of that into one centralized view inside the MainWP Dashboard.

The official documentation describes the extension as a standalone add-on for MainWP Dashboard: it checks the SSL certificates of HTTPS Child sites, shows the expiration date, issuer, and common name, provides detailed certificate information, supports automated checks, and lets you override global settings for an individual site. The product page also mentions email alerts, manual checks, status visibility in Manage Sites, and status logging.

It is important to understand the product boundaries correctly. It does not issue certificates, does not configure Let's Encrypt on the server, does not change DNS, and does not automatically repair a broken certificate chain. What it does is help you spot a problem before a client or visitor does. That makes the extension especially useful for care plans where the administrator is responsible not only for updating WordPress, but also for watching basic availability, browser trust, and the overall technical health of the domain.

In practical terms, MainWP SSL Monitor answers four questions:

• Which connected sites have SSL certificates that are about to expire.
• Which certificate authority issued the certificate and what name is listed as the common name.
• When the last automatic or manual check was run.
• Whether a particular site should use the global monitoring mode or its own custom settings.

That is enough to make SSL monitoring part of your regular maintenance workflow. For example, an administrator may review updates and backups on Mondays, while SSL Monitor provides a separate early warning signal for certificates. If the email arrives in advance, the team has time to verify auto-renewal at the host, confirm DNS, open a provider ticket, and notify the client without rushing through an avoidable emergency.

Who This Extension Is For, and When It Is Overkill

MainWP SSL Monitor is especially useful when you already have a MainWP Dashboard and several connected Child sites. The more sites you manage, the higher the chance that one certificate will expire at the worst possible time: after a migration, after a domain change, after a DNS error, after auto-renewal is disabled, or after moving a site from a temporary domain to production. The extension does not require any additional plugin on each Child site beyond MainWP Child, so it fits neatly into an existing MainWP setup.

Who Should Enable SSL Monitor

A good fit is an agency or freelancer maintaining multiple client WordPress sites and handling technical support. In that scenario, SSL is not an abstract security feature. It is part of the service agreement: if the browser shows an untrusted certificate warning, the client sees it as a broken site. The extension is also useful for someone managing a network of their own projects, especially when those sites are spread across multiple hosting providers.

There are narrower use cases too. An ecommerce store can lose visitor trust over any HTTPS issue, and a lead generation site with forms may see lower conversions if the browser starts showing warnings. MainWP SSL Monitor does not directly affect SEO, but it helps prevent the kind of technical situation where a site appears unsafe to both users and search engines.

When You Can Skip It

If you have one site, one hosting provider, and reliable built-in provider notifications, separate monitoring through MainWP may be unnecessary. For a small project, it may be easier to rely on hosting alerts and occasionally check the certificate with an external SSL checker. The extension also will not solve the problem if the site is not connected to MainWP Dashboard at all, or if your organization already uses another centralized monitoring service with SSL alerts configured.

Practical rule of thumb: if you already maintain client sites through MainWP and check updates, uptime, or reports in the Dashboard, adding SSL monitoring is a logical next step. If you do not use MainWP yet, start by deciding whether MainWP itself makes sense for you as a self-hosted site management platform.

What to Check Before Installing the Extension

Preparation matters because SSL Monitor errors often turn out not to be extension errors at all, but issues with MainWP connectivity, email delivery, or the site's SSL setup. Before installation, it is worth confirming that MainWP Dashboard is installed on a separate WordPress site, the Child plugin is active on the managed sites, and the connection between Dashboard and Child sites works without errors.

MainWP's official materials recommend using a separate WordPress install for the Dashboard, rather than a public production site with visitors. That reduces the risk of conflicts and makes troubleshooting easier. For Child sites, an active MainWP Child connection is required. If a site does not appear in MainWP > Sites > Manage Sites, SSL Monitor will not magically start checking its certificate.

Basic Pre-Installation Checklist

• The Dashboard runs on a separate WordPress installation and meets MainWP system requirements.
• MainWP Child is installed and active on every target site.
• The sites appear and sync in MainWP > Sites > Manage Sites.
• Test Connection for problematic sites returns a successful result or a clear HTTP status.
• Email delivery is configured on the Dashboard, because certificate notifications are useless if WordPress cannot send mail.
• The sites you want to monitor actually use HTTPS, and the certificate is issued for the correct domain name.

If MainWP already has connection issues, fix those first. The connection issues documentation lists common causes such as WAF blocking, ModSecurity, Imunify360, Cloudflare, DNS cache, SSL verification issues, and OpenSSL errors on the server. This is critical for SSL Monitor: the extension checks certificates from the Dashboard's point of view, so the result may differ from what you see in your own browser.

Email and Notifications

The main value of the extension is giving you advance notice before a certificate expires. That means you should verify outbound mail from the Dashboard before enabling automated checks. If WordPress is using an unconfigured mail(), messages may land in spam or fail to send entirely. In that situation, it is safer to configure an SMTP plugin on the Dashboard site and send a test email before relying on SSL alerts.

Installing the Extension and Running the First Check

MainWP SSL Monitor is installed from the MainWP Dashboard through the add-ons page. The documentation describes the standard path: open MainWP > Add-ons > Manage Add-ons, click Install Add-ons, find SSL Monitor, then install and activate the add-on. Do not confuse this with installing a normal WordPress plugin on every client site. The extension is installed on the Dashboard, while Child sites are already connected through MainWP Child.

Step-by-Step Process

1. Open the WordPress admin panel where MainWP Dashboard is installed.
2. Go to MainWP > Add-ons > Manage Add-ons.
3. Click Install Add-ons and find SSL Monitor.
4. Install the extension, then click Activate Add-ons.
5. Open MainWP > Add-ons > Monitoring > SSL Monitor > Dashboard.
6. Run a check for all sites using Check SSL Certificate on All Sites.

After the first check, do not rush to change every setting right away. First, review the results table: which sites appear, where expiration dates are populated, which issuer is listed, and whether the common name matches the domain you expect. If some sites are missing or show a strange status, that is a sign to verify whether they are connected as Child sites, whether they actually work over HTTPS, and whether the server is blocking requests from the Dashboard.

How to Check a Single Site Separately

A bulk check is useful right after installation, but in day-to-day work you will usually need to inspect one specific site. The documentation shows the path through the SSL Monitor table: find the site, open the three-dot menu, and choose Check SSL Certificate. This is useful after a manual certificate renewal, a DNS change, a site migration to a new server, or a certificate chain fix at the host.

Checking a single site saves time and reduces noise. If only one domain has updated its certificate, there is no reason to rerun the entire list. But after a large migration or CDN replacement, it is better to check all sites so you can see the full picture and avoid missing a project that appears to load externally but serves the wrong certificate to MainWP Dashboard.

How to Read the SSL Monitor Table and Certificate Details

The extension's main working screen is the table on the SSL Monitor Dashboard page. According to the documentation, it shows key certificate details: expiration date, issuer, and common name. The product page also notes that SSL Status can be visible directly on the Manage Sites screen. For an administrator, that means two levels of control: a quick indicator in the site list and a detailed certificate card inside the extension itself.

The most common mistake when reading the SSL table is looking only at the date. The date matters, but it is not the only thing that matters. If the common name or SAN does not match the domain, the browser may still complain even if the certificate has not formally expired. If the issuer suddenly changes after a migration, that is not automatically a problem, but it is worth checking whether the host issued the certificate through the expected certificate authority and whether the trust chain is still valid.

What Each Data Group Means

For a more detailed view, the documentation recommends opening the SSL Certificate Info action from the three-dot menu. This mode is worth using even when there is no visible problem. It helps build the right habit: if a site is important, open the certificate details after renewal and confirm that the certificate belongs to the correct domain, not just that it looks "green" in the list.

Quick takeaway: the SSL Monitor table answers the question "where is the risk," while the certificate details answer the question "what exactly changed." Do not use the first as a substitute for the second when an important client domain is involved.

Configuring the Notification Threshold and Automated Checks

After the first manual check, move on to the settings. In the documentation, they are located at MainWP > Add-ons > Monitoring > SSL Monitor > Settings. The main options are Notifications threshold (days) and Automated Checks with the frequency of automatic checking. It is a small set of options, but it determines whether the extension actually helps or simply stores a certificate table.

How to Choose a Notification Threshold

The threshold in days should take into account not only the certificate lifetime, but also your real remediation process. If all sites are on one hosting provider with reliable auto-renewal, a moderate buffer may be enough. If the sites are spread across multiple providers, some clients pay for hosting themselves, and DNS changes sometimes happen without informing the support team, it is better to allow more time. The key rule is simple: the threshold should leave enough time for human communication, not just the technical fix.

For an agency, it helps to think in service cycles. If support is reviewed once a week, the threshold should let you spot a problem at least one full cycle before the certificate expires. If the client needs to approve hosting access or payment, add more buffer. If the site is critical, such as a store, a lead portal, or an account area, it is safer to receive the warning earlier and not treat the email as something that must be handled "tonight."

Automated Checks: Enable Them or Run Everything Manually?

Automated Checks should be enabled for most production sites, because automation is what turns the extension into real monitoring. Manual checks are still useful after events like renewals, migrations, DNS changes, CDN connections, primary domain changes, or adding a new Child site. But if you rely only on manual mode, MainWP SSL Monitor becomes just another table that is easy to forget to open.

Choose the automated check frequency without overdoing it. SSL certificates do not change every minute, so overly frequent checks rarely provide much benefit. Base the schedule on how often you are ready to receive and act on notifications. If the Dashboard contains many sites, checks should be regular, but not so frequent that they turn into noise the administrator starts ignoring.

What to Verify After Saving

1. Save the settings with the Save Settings button.
2. Run a manual check for all sites and confirm that the table updates.
3. Verify Dashboard email delivery with a test message from your SMTP plugin or another built-in WordPress method.
4. Open the certificate details for one test site and confirm that the data looks as expected.
5. Document an internal team rule: who responds to SSL notifications and where the result is recorded.

If emails stop arriving after you change the settings, do not immediately start changing SSL Monitor itself. First, verify email delivery from the Dashboard. MainWP documentation notes that email delivery issues are often tied to mail() and spam filtering, and that using an SMTP plugin is the more reliable approach. This is especially important for SSL Monitor: a missing email may look like "the extension is silent" when the real problem is that the message was never delivered.

Best Settings for Different Types of Site Portfolios

There is no universal threshold value, because SSL risk depends not just on the site itself, but on who controls hosting, DNS, domain billing, CDN, and email notifications. That is why MainWP SSL Monitor settings are best chosen by portfolio type rather than by guesswork. This reduces noise and helps you decide in advance where an earlier warning is necessary and where a standard level of monitoring is enough.

The main idea is simple: the notification threshold should match the response time. If the administrator can log into the hosting panel and restart certificate issuance personally, one kind of buffer makes sense. If someone first has to email the client, wait for access, open a provider ticket, and verify DNS, the buffer should be larger. If the site sits on a client's unknown hosting setup, monitoring should warn you earlier than it would for sites on your own infrastructure.

Portfolio on Your Managed Hosting

When all sites are hosted on the agency's managed hosting, the process is usually the most predictable. You know where auto-renewal is enabled, who receives the host's system emails, where to review SSL logs, and how quickly a support ticket can be opened. For these sites, a single global mode usually works: automated checks enabled, one shared threshold, and very few exceptions.

Even in this case, though, you should not rely on the host alone. Auto-renewal can fail because of DNS, temporary ACME request blocking, certificate authority limits, or panel errors. SSL Monitor is not there to do the host's job. Its role is to provide an independent signal inside your service Dashboard. If the host says "everything renews automatically" but MainWP shows an approaching expiration date, that is a reason to verify, not to argue with the tool.

Sites on Client Hosting

The riskiest scenario is a site where the client pays for hosting and the domain directly. You may support WordPress technically, but access to the hosting panel may be incomplete or granted only when requested. In that situation, an early notification threshold matters more than it does on your own servers. An email a few days before expiration may be far too late if the client replies slowly or the provider requires account owner confirmation.

For these sites, it makes sense to use an individual override. Inside MainWP, this should not be a hidden setting used just for appearance. Add a note to the client record: "SSL is managed by the client, MainWP only warns us." That way, the alert does not get lost between technical responsibility and account management responsibility. When the team sees an early warning, it can proactively ask the client to verify billing, hosting access, and auto-renewal settings.

CDNs, Proxies, and Unusual Certificate Chains

Sites behind Cloudflare, a reverse proxy, or a separate CDN require more careful interpretation. Visitors may see the CDN certificate, while the origin server uses a different one. Depending on the setup, the Dashboard may check the public domain and receive exactly the certificate that outside visitors see. That is normal if the site is supposed to work that way. The problem begins when the CDN is disabled, DNS is switched, and the origin server certificate is not ready.

For those sites, document the expected setup: where the public certificate is issued, who is responsible for renewal, which domain should appear in the common name or SAN, and what to do after changing proxy mode. MainWP SSL Monitor gives you data, but it does not know your architectural decisions. If the issuer changes after enabling a CDN, that may be normal. If the common name suddenly points to an old domain, that is a real reason to investigate.

Staging, Dev, and Archived Sites

Test environments often create unnecessary noise. They may use temporary domains, basic auth, self-signed certificates, restricted access, or no HTTPS at all. If those sites are included in general monitoring without any context, the administrator will receive meaningless alerts over and over again and eventually stop trusting the system. It is better to decide up front which environments should be monitored and which should not.

If staging is used for client demos, HTTPS still matters there. In that case, do not disable monitoring completely. Instead, give it a separate rule and tag the site or leave a note. If the environment is internal and not publicly accessible, SSL monitoring may not be necessary. The important thing is not to leave the exception undocumented.

Working Decision Table

Once you classify sites this way, MainWP SSL Monitor becomes much easier to configure: start with a common mode for most sites, then define the remaining 5 to 10 percent as deliberate exceptions. If you have more exceptions than that, the problem is usually not the extension. It is an unmanaged site portfolio.

Individual Rules for Specific Child Sites

Not every site in a portfolio is the same. One client may have a critical store, another an archived landing page, and a third a staging environment on a temporary domain that should not appear in the general SSL report. That is why MainWP SSL Monitor includes site-level settings: you can open a specific Child site, go to SSL Monitor > Settings, and enable Overwrite general settings.

This is useful when your global policy is too broad. For example, one notification threshold may be fine for most sites, but a few critical domains need an earlier warning. Or the opposite: a test site on an internal domain should not generate false notifications in the shared stream. The key is not to overuse overrides, or within a few months nobody will remember why one particular site is operating under a separate rule.

When to Override Global Settings

• The site is critical for sales, lead capture, or customer account access, so it needs an earlier warning threshold.
• The site uses a non-standard SSL setup: CDN, reverse proxy, temporary domain, or a separate certificate managed by the client.
• The site is no longer actively maintained but still remains in the Dashboard for historical reference.
• A staging or dev environment should not interfere with the overall production report.
• The client manages hosting directly, so the support team needs more buffer time for communication.

How to Keep Exceptions Under Control

Every exception should have an internal note attached to it. That may be a comment in your CRM, a tag in MainWP, a custom client field, or a support document. The logic is simple: if a new administrator sees six months later that automated SSL checking is disabled for a site, they should immediately understand why. Without that discipline, individual settings become a source of risk.

A practical approach is to group sites as production, critical, staging, archived, or client-hosted with external infrastructure. Then define a threshold and automated check rule for each group. MainWP SSL Monitor does not have to be the only place where this classification is stored, but its site-specific settings should reflect your actual support model.

Practical Scenario: Rolling Out SSL Monitoring Across a Client Portfolio

Consider a real-world task. An agency has a MainWP Dashboard and twenty client sites. Some are hosted on your infrastructure, some on client hosting, and several projects were recently moved to a new server. You need to enable SSL monitoring so the team gets early warnings, can quickly verify a single domain after renewal, and does not waste time reacting to noise from test environments.

Goal

Create one consistent process: automated SSL checking runs for all production sites, critical sites warn earlier, staging sites do not create false tasks, and after any SSL-related change the administrator runs a manual check and records the result.

Preparation

• MainWP Dashboard is installed on a separate WordPress site.
• MainWP Child is active and connected on all sites in the portfolio.
• The sites sync in Manage Sites.
• Email delivery from the Dashboard has been verified through SMTP or another reliable channel.
• The site list is divided into production, critical, and test environments.

Configuration Steps

1. Install and activate MainWP SSL Monitor through Manage Add-ons.
2. Open the extension dashboard and run Check SSL Certificate on All Sites.
3. Review the table: every production HTTPS site should show certificate data.
4. In Settings, enable automated checks and set a notification threshold that matches your support cycle.
5. For critical sites, open the individual site dashboard, go to SSL Monitor > Settings, enable Overwrite general settings, and assign an earlier threshold.
6. For staging sites or archived projects, decide whether monitoring is needed. If not, disable it at the site level and document the reason.
7. After renewing a certificate on one domain, run a targeted Check SSL Certificate from the site menu in the table.

Expected Result and Verification

As a result, the administrator sees SSL status in MainWP, receives email alerts before certificate expiration, and can open detailed certificate information for any site. The setup is successful if the bulk check updates the table, a single site can be checked manually, Dashboard emails are being delivered, and individual overrides do not break the overall monitoring model.

Post-Migration Detail

After moving a site to a new server, DNS may not update at the same pace for every resolver. The administrator's browser may already see the new IP, while the Dashboard may still be reaching the old address because of DNS cache on the hosting side. If SSL Monitor shows an unexpected certificate immediately after migration, compare the IP used in the MainWP connection test, an external DNS checker, and the hosting panel. Do not change the notification threshold until you are sure the Dashboard is checking the same server your visitors are supposed to reach.

Verifying the Result After Setup

Once the extension is enabled, you need to confirm that the process actually works. Formally installing the add-on is not the same as having working monitoring. You need a short acceptance check: the table updates, certificates are readable, email delivery is confirmed, exceptions make sense, and the team knows how to respond to a warning. Without that, SSL Monitor may be active but still provide no real value.

Mini Audit After Day One

• Open SSL Monitor > Dashboard and make sure the data is not empty.
• Compare 2 to 3 certificates with an external SSL checker or the hosting panel.
• Confirm that SSL Status in Manage Sites helps you spot problematic sites quickly.
• Open the details for one certificate through SSL Certificate Info.
• Run a manual check on one site after any controlled change.
• Verify that the team receives Dashboard emails and knows where to forward them or where to create a task.

If you provide client reports, do not promise that "certificates will never expire." A more accurate way to describe the process is: the team tracks SSL expiration and responds to early warnings. That is both more honest and more technically precise, because the actual renewal still depends on the hosting provider, DNS, certificate authority, and domain access.

How to Tie SSL Monitor Into Ongoing Maintenance

A good practice is to add SSL review to your weekly or monthly maintenance checklist. For example: site sync, updates, backups, uptime, SSL, domains, vulnerabilities. MainWP already offers separate monitoring add-ons, including Domain Monitor and Advanced Uptime Monitor, so SSL Monitor works best as one part of a broader site health map rather than as a standalone button.

This also helps you avoid mixing up root causes. If a site is unavailable, the reason may be an uptime issue, an expired domain, a DNS error, an expired SSL certificate, or blocked MainWP requests. When each layer is monitored separately, troubleshooting gets faster: Domain Monitor covers the domain, Uptime Monitor covers availability, SSL Monitor covers the certificate, and the connection test covers communication between the Dashboard and the Child site.

Limitations and Cautious Configuration

MainWP SSL Monitor solves a narrow problem and should not be treated as a full security scanner. It shows certificate status, helps you plan renewals, and lets you spot changes, but it does not replace vulnerability scanning, HTTPS configuration on the server, mixed content checks, HSTS, security headers, or form security reviews. That is not a weakness of the product. It is a normal boundary of responsibility.

What the Extension Does Not Do

• It does not issue or renew the certificate on the hosting side.
• It does not fix DNS if the domain points to the wrong server.
• It does not repair the certificate chain or add intermediate certificates.
• It does not automatically scan the whole site for mixed content.
• It does not guarantee email delivery if Dashboard mail is configured poorly.
• It does not replace external uptime monitoring for critical sites.

When to Disable Monitoring for a Site

Disabling monitoring should only be done intentionally. Valid cases include: the site is no longer under maintenance, a temporary environment should not be checked, the domain has not been moved to HTTPS yet, or the client manages SSL independently and it is outside your care plan. In most other cases, it is better not to disable monitoring, but to set an individual threshold or fix the reason for the false signal.

If a site uses a self-signed certificate, a restricted staging environment, or an unusual access model, MainWP may also run into SSL verification issues when connecting to the Child site itself. In the connection issues documentation, MainWP suggests disabling SSL certificate verification for a specific site in the connection settings in some cases, but that setting applies to the MainWP-to-Child connection, not to the public meaning of HTTPS for visitors. Only do this if you understand why the certificate should not be verified in the standard way.

SSL Monitor, DNS, and the Real Causes of False Alerts

SSL guides often focus only on expiration dates, but in WordPress support work, most strange cases are caused by the infrastructure around the certificate. MainWP SSL Monitor shows the result of the check. The administrator still has to understand why that result appeared. Once you learn to read the signal in the context of DNS, CDN, and Dashboard-to-Child communication, false alerts become much less common.

DNS After a Migration

After moving a site, DNS may update unevenly. Your browser may already reach the new server, an external checker may show a mixed result, and the Dashboard server may still see the old IP. In SSL Monitor, that can look like an unexpected certificate, an old issuer, or a date that does not match the new hosting panel. Do not rush to disable monitoring. First, check which IP the Dashboard sees, what public DNS shows, and on which server the new certificate was actually issued.

If the mismatch is caused by DNS cache, the solution is usually not inside SSL Monitor. You need to check DNS records, TTL, and the cache on both the Dashboard host and the Child site side. After DNS stabilizes, run a manual check. If the data updates correctly, record in the task that the issue was temporary and migration-related. That helps prevent a duplicate investigation the next time a similar situation happens.

CDNs and Different Certificates at Different Layers

A site behind a CDN may have a public edge certificate and a separate origin certificate on the server. The public certificate is what matters to the visitor, but the origin must still be configured correctly, especially if the CDN requires a strict validation mode. MainWP SSL Monitor usually checks the public domain, so it helps you see what an outside visitor should see. But if you change CDN mode, temporarily disable proxying, or move the origin, the data may change abruptly.

A practical way to reduce confusion is to store a short architecture note in the site's documentation: "the domain is proxied through a CDN, the public SSL is issued by the CDN, the origin SSL is issued by the host." Then when an alert appears, the administrator immediately knows where to look. Without that note, the team may spend time on the wrong layer, renewing the origin when the edge certificate is the one expiring, or the other way around.

The Certificate Is Valid, but the MainWP Connection Test Fails

SSL Monitor and the connection test solve different problems, but in real troubleshooting they often intersect. A site may have a valid public certificate while requests from MainWP Dashboard are being blocked by a WAF or a security plugin. Or the reverse: the connection to the Child site works, but the public certificate is close to expiring. So do not assume "the certificate looks fine, therefore MainWP should connect." Check visitor-facing HTTPS, Dashboard-to-Child communication, and notification delivery separately.

MainWP's connection issues documentation explicitly points to firewall rules, ModSecurity, Imunify360, Cloudflare, DNS, and OpenSSL. Those causes matter for SSL Monitor as well, because the extension works inside the same administrative ecosystem. If a WAF is blocking MainWP, fix the block according to the documentation first, then return to the certificate check.

Common SSL Monitor Problems and How to Diagnose Them

Most MainWP SSL Monitor issues are easier to troubleshoot by symptom than by asking whether "the plugin works." First identify what exactly is broken: the site does not appear, the table does not update, the email never arrives, the certificate looks wrong, or MainWP cannot communicate with the Child site at all. Then inspect the closest layer: connectivity, HTTPS, DNS, email, or site-specific settings.

The Site Does Not Appear in the SSL Monitor Table

Symptom: the site exists for the client, but you do not see the expected row on the SSL Monitor page, or the data never updates. A likely cause is that the site is not connected as a Child site, the Dashboard connection is broken, the site is not running over HTTPS, or the request is being blocked by a security layer.

Start by checking MainWP > Sites > Manage Sites and run Test Connection. If the connection fails, resolve the connection issue before looking at SSL Monitor. MainWP documentation separately covers Cloudflare blocking, ModSecurity, Imunify360, DNS, and server-side errors. Adjusting SSL Monitor settings while the Dashboard cannot communicate with the site is pointless, because the extension will not be able to produce a reliable result.

The Certificate Looks Expired Even Though the Browser Looks Fine

Symptom: the administrator's browser shows valid HTTPS, but MainWP SSL Monitor sees an old or suspicious certificate. Common causes include DNS cache, a recent migration, CDN behavior, reverse proxying, or different server responses from different check points.

Check the IP address seen by MainWP Dashboard and compare it with the site's expected IP. After a migration, ask the Dashboard host to clear DNS cache if the result is obviously stale. Then run a manual Check SSL Certificate for that specific site. If the problem disappears, do not change the global settings. If it remains, verify the certificate with an external SSL checker and in the hosting panel.

Certificate Emails Are Not Arriving

Symptom: the table updates, but the email alerts never reach the responsible administrator. A likely cause is that WordPress mail on the Dashboard is not configured, messages are being filtered as spam, the sender address looks untrusted, or the alert is expected before the configured threshold.

Check whether the Notifications threshold (days) condition has actually been reached. Then send a test email from the Dashboard site. If the test fails, configure an SMTP plugin and try again. Do not increase the SSL check frequency just to debug email delivery. If the mail layer is broken, more frequent checks will not help.

Too Many Notifications Appeared After Enabling Automated Checks

Symptom: the team starts receiving emails for sites that do not need action: staging environments, archives, old domains, or temporary setups. The cause is usually not technical, but organizational. Monitoring was enabled for sites with different support statuses.

Split the sites into groups and use individual settings. For staging, you can disable monitoring or apply a separate rule if SSL still matters there. For production sites, it is usually better not to disable the signal, but to choose a threshold that matches your workflow. If the alert is for a client who manages SSL independently, note that in the client record so the team does not waste time on repeated diagnosis.

MainWP Shows an SSL Verification Error During Connection

Symptom: the issue appears not in the certificate table, but while connecting to or checking the Child site. MainWP documentation notes that misconfiguration or an expired SSL certificate can prevent the Dashboard from connecting to the Child site. A quick workaround for a specific site is the Verify SSL Certificate setting in the site parameters, but it should not be used as a universal fix.

First verify the site's real certificate and trust chain. If the public site certificate is supposed to be valid, fix the problem at the hosting or CDN level. Disabling verification is acceptable only in deliberate non-standard cases, such as an internal environment where normal public certificate validation does not apply. After making a change, always rerun the connection test and a manual SSL check.

When It Is Better to Roll Back a Setting

Roll settings back if, after an individual override, the site stops behaving as expected, if automated checks create noise without value, or if disabling SSL verification starts masking a real problem on a production domain. The safest rollback is to return to global settings, run a manual check, and then decide again whether the site truly needs an exception.

How to Integrate SSL Monitor Into Reports, Procedures, and Team Workflows

Monitoring alone does not solve anything if nobody responds to the signal. That is why, after the technical setup, it is worth documenting a procedure. It should specify who receives the email, what response time is considered normal, where the task is created, how the fix is verified, and when the client is notified. For a small team, that may be a simple task manager note. For an agency, it should become part of the standard care process.

It is useful to tie SSL Monitor to three events. First, the regular review of site status. Second, the response to an approaching-expiration email. Third, the manual check after any domain-related change. When the team acts according to those events, the extension stops being "just another page in the admin" and becomes a task source with a clear lifecycle.

Sample Internal Procedure

1. Every SSL alert becomes a task with the domain, deadline, and responsible person.
2. The administrator checks the certificate in SSL Monitor, an external SSL checker, and the hosting panel.
3. If renewal depends on the client, the account manager requests access or confirmation.
4. After the fix, the administrator runs a manual Check SSL Certificate.
5. The result is recorded in the task: check date, status, and what was changed.

For client reports, you can summarize the outcome without unnecessary technical detail: "The SSL certificate was checked, the expiration period is under control, and warnings are enabled." If the certificate was close to expiring and the issue was resolved, mention it as completed preventive maintenance. That way, the client sees not only plugin updates, but the real value of ongoing technical support.

When MainWP SSL Monitor Is the Right Choice

MainWP SSL Monitor is worth using if you already have a MainWP Dashboard, several connected WordPress sites, and a responsibility to respond to SSL risk before it becomes visible to clients or visitors. The extension fits especially well into an agency workflow: bulk checks, a clear certificate list, manual checks after changes, global settings, and overrides for individual sites. It does not try to be a universal security suite, but it solves one very specific pain point well - preventing certificate expiration from slipping through in a site portfolio.

Before rolling it out, verify the basic Dashboard-to-Child setup, system requirements, email delivery, and the HTTPS status of the sites themselves. After installation, do not stop at activation. Run the first bulk check, configure the notification threshold, enable automated checks, define rules for critical sites, and decide within the team who responds to the emails.

If that workflow matches your process, you can get the MainWP SSL Monitor file and test it safely on a small group of sites: one standard production site, one critical project, and one environment that needs an individual rule. That kind of pilot will quickly show how naturally the extension fits into your support process and which exceptions should be documented in your internal procedures.