Before Clients Say “Your Site Says It’s Not Secure”: How to Build a Maintenance Workflow That Prevents SSL Certificate Oversights

“A client told us, ‘The site says it’s not secure,’ and we rushed to check what was happening.”

If you are involved in website maintenance, you may have experienced a moment like this.

Managing SSL certificate expiration dates is one of the most basic parts of a maintenance contract.
Still, when management sheets are not updated, responsibilities are not properly handed over, or each site has a different renewal schedule, manual management alone can lead to missed issues.

We have also experienced a case where we first noticed an expired SSL certificate because a client pointed it out.

Once the certificate is reissued and applied, the browser warning itself can be resolved.
However, the fact that the client or site visitor noticed it before we did remains a serious reflection point for the maintenance provider.

In addition, from March 15, 2026, the validity period for SSL/TLS certificates was shortened from 398 days to 200 days. It is scheduled to be shortened further to 100 days on March 15, 2027, and to 47 days on March 15, 2029.

In other words, renewal work that used to happen roughly once a year will increase to twice a year, and eventually to seven or eight times a year.

In this article, we explain how we reviewed our maintenance workflow so that SSL certificate expirations and post-renewal issues can be detected by our own team before clients point them out.

---

Why This Problem Happens

Problems with SSL certificate management do not happen simply because someone “forgot.”

As the number of websites under maintenance increases, certificate renewals become more frequent, and the number of post-renewal checks grows, traditional management methods become harder to sustain.

Background 1: SSL/TLS Certificate Validity Periods Are Becoming Shorter, Increasing Renewal Frequency

From March 15, 2026, the validity period for SSL/TLS certificates was shortened from 398 days to 200 days.
This change was decided through CA/Browser Forum ballot “SC-081v3.”

The period is scheduled to become even shorter in stages: 100 days on March 15, 2027, and 47 days on March 15, 2029.

It is not only the certificate validity period that will become shorter.
The reuse period for domain control validation, or DCV information, used when issuing certificates will also be reduced in stages, eventually reaching 10 days in 2029.

This means that website maintenance teams will face the following two tasks more often than before:

• Renewing SSL certificates
• Revalidating domain control

As renewal frequency increases, the chances of missing a check also increase.
We felt that simply managing expiration dates in a spreadsheet and setting notifications would place a growing burden on operations.

Background 2: Expiration-Date Management Alone Cannot Detect Post-Renewal Issues

Renewing an SSL certificate does not end with issuing a new certificate and applying it to the server.

Even if the renewal work itself is complete, other issues may remain on the website side.

For example, in our own operations, we have seen issues such as:

• Images or scripts hardcoded with HTTP remained and caused mixed content warnings
• Images written with relative paths failed to load in an HTTPS environment
• External scripts such as ad tags or chat widgets still referenced HTTP and were blocked by the browser
• Parts of the site still used a certificate for an old subdomain, causing warnings on specific pages

These issues cannot be detected by only checking the certificate expiration date.

Even if a management sheet says “renewed,” you may not notice visitor-side issues unless you actually crawl the site and confirm that it displays correctly over HTTPS.

In May 2026, Cloudflare reported an issue in which some visitors experienced TLS connection problems with certain Let’s Encrypt certificates due to intermediate CA chain embedding.

This shows that even when a server appears to have a renewed certificate, warnings or connection failures can still occur depending on the browser or environment.

That is why SSL certificate maintenance requires not only “managing expiration dates” but also “checking what happens on the site after renewal.”

---

Steps to Solve the Problem

We reviewed our maintenance workflow so that the timing of detection could move from “client-reported” to “our own regular checks.”

Broadly speaking, we organized the workflow into three steps.

STEP 1: Visualize the Current Situation

The first thing we did was organize the SSL certificate status and check items for each website under maintenance.

Previously, we managed SSL certificate expiration dates in a spreadsheet.
We had notifications set up as deadlines approached, but renewal timing differed from site to site. In some cases, we missed things because of staff changes or management sheet update omissions.

So instead of only looking at “expiration dates,” we began checking from perspectives such as:

• Which sites are due for renewal and when
• Which pages should be checked before and after renewal
• Which pages had SSL-related issues in the past
• Where mixed content or image-loading failures tend to occur
• Whether HTTP references remain in external scripts or tags

The important point here is not to limit SSL certificate management to a simple list of expiration dates.

By visualizing not only deadlines but also pages and elements that should be checked after renewal, it becomes easier to reduce operational oversights.

STEP 2: Record and List Issues as Part of Monthly Operations

Next, we incorporated site crawling before and after SSL certificate renewal into our monthly operations, so that potential issues could be listed.

For this, we use MONJI+’s “Website Anomaly Detection & Improvement” feature.

With MONJI+, you can enter a URL and automatically crawl pages within the site in both desktop and smartphone views, then generate a list of potential anomalies.

Examples of items to check after SSL renewal include:

• Broken links during HTTPS access
• Image-loading failures
• Display issues caused by mixed content
• Missing tags
• External scripts that still reference HTTP

Previously, manual checks took more than five hours per site per month, and SSL-related checks and responses accounted for a certain portion of that time.

However, now that the SSL/TLS certificate validity period has been shortened to 200 days and will become even shorter in the future, relying only on the same manual approach will become harder to sustain.

For that reason, we decided to leave mechanically detectable items to tools like MONJI+ and use human time for checks that require judgment.

STEP 3: Use Several Months of Records for Discussions and Proposals

For SSL certificate maintenance, detection alone is not enough. It is important to connect detection to response and recordkeeping.

Our monthly cycle works as follows:

1. Run anomaly detection manually or on a regular schedule around the certificate renewal date
2. Create correction requests for items that require action based on the detection results
3. Assign a person in charge and handle the issue
4. After the response, check the impact range using Google Analytics
5. Store “points to watch for the next renewal” in the Wiki

The Wiki accumulation has been especially useful.

For example, if mixed content appeared on a specific page in the past, an external tag still referenced HTTP, or a certain subdomain required certificate-related checks, we keep that information so it can be included from the start during the next SSL renewal.

As renewal frequency increases to twice a year, and eventually to seven or eight times a year, reflecting past crawl results in the next checklist becomes increasingly valuable.

These operational records also make it easier to explain to clients what was checked, what anomalies were handled, and how those findings will be used next time.

When reviewing maintenance fees or operational scope, it becomes easier to position the work not merely as “hours spent,” but as an operation designed to detect risks in advance.

---

What Actually Changed

After revising the maintenance workflow, the biggest change was the timing of detection.

Previously, we manually managed SSL certificate expiration dates in spreadsheets and checked the server, DNS, and website display by hand whenever renewal dates approached.

If there was an expiration or renewal configuration error, we sometimes only noticed it after a browser warning appeared or a client pointed it out.

After incorporating MONJI+ into our maintenance workflow, we became able to run automatic crawls after SSL renewal and detect issues such as broken links during HTTPS access, image-loading failures, and display problems caused by mixed content.

The detection results can be turned directly into correction requests.
Points for preventing recurrence are also accumulated in the Wiki.

As a result, the timing of detecting expiration and post-renewal issues moved from “client-reported” to “our own regular checks.”

The more often SSL certificates need to be renewed, the larger the number of opportunities for oversight becomes.
Given that premise, redesigning the way we notice problems in advance has been meaningful for our team.

It also reduced the mental burden on maintenance staff.

There is a real difference between working under the anxiety that “someone might contact us after something goes wrong” and operating with the confidence that “we are checking regularly.”

---

Notes and Limitations

That said, automatic detection cannot cover everything.

Automatic detection is good at identifying issues that can be judged mechanically.

For example:

• HTTP status codes
• Whether image files load successfully
• Whether tags are present
• Whether links are reachable
• Potential mixed content

On the other hand, some items still require human eyes and hands.

For example, subtle design misalignments, animation behavior, form submission behavior, and detailed issues related to intermediate CA certificate chains cannot always be judged through mechanical pass/fail checks alone.

Also, automating SSL certificate issuance and renewal itself depends on the hosting provider, certificate management method, and whether ACME is supported.
This is outside the direct scope of what MONJI+ covers.

Therefore, we currently divide responsibilities as follows:

• Use existing automatic renewal services such as ACME for certificate issuance and renewal
• Use MONJI+ to crawl and check post-renewal effects such as broken links, image-loading failures, and mixed content
• Have team members manually check items that require human judgment, such as design and form behavior

Looking ahead to 2027 and 2029, when certificate validity periods will become even shorter, we believe this separation will become more important: automate issuance, and use crawling to absorb the impact checks after renewal.

---

MONJI+: A Website Operations Support Platform Born from the Field

SSL certificate post-renewal checks are only one example.
In website operations, detailed checks, correction requests, and recurrence-prevention records occur every day.

The platform created to solve the challenges we have felt in the field is MONJI+, a website operations support platform.

MONJI+ brings the “people” involved in website operations together as one “team,” helping solve issues across all phases of website operations.

We are not trying to build a “complete product” from the beginning.

The real challenges we need to face exist in the field of website operations.
That is why we have continued to listen to the real voices of people working there.

By taking in each piece of feedback, resolving small frustrations through repeated updates, and developing new features from actual field challenges, MONJI+ has grown with the support of users in 77 countries around the world.

▼ Learn more about MONJI+ here
https://monji.tech/ja/plus/

A world where people working in website operations can proudly say, “I love this work.”

▼ We welcome your voice as we work toward making that world a reality
https://monji.tech/ja/plus/co-creation/

---

Summary

From March 15, 2026, the validity period for SSL/TLS certificates was shortened from 398 days to 200 days.
It is scheduled to be shortened to 100 days on March 15, 2027, and to 47 days on March 15, 2029, while the reuse period for domain validation information will also be reduced in stages.

As a result, SSL certificate renewals in website maintenance will increase from once a year to twice a year, and eventually to seven or eight times a year.

That is why future maintenance operations cannot rely only on expiration-date management.

The important points are:

1. Visualize SSL certificate expiration dates and renewal schedules
2. Crawl the site after renewal and check for broken links, image-loading failures, mixed content, and related issues
3. Turn detection results into correction requests and Wiki records, then use them for the next renewal

SSL expiration and HTTPS-related anomalies are areas where the outcome changes significantly depending on whether you can notice the issue early.

Instead of responding after a client says, “The site says it’s not secure,” create a workflow where your own regular checks detect issues first.

To do this, we have incorporated MONJI+’s “Website Anomaly Detection & Improvement” feature into our maintenance workflow and positioned SSL post-renewal checks as part of monthly operations.

As certificate validity periods become shorter, we believe this kind of steady operational design will become an increasingly important foundation for protecting client trust.