A customer follows a link to your website and sees “Your connection is not private”. Your team can still open the homepage, and the hosting panel says SSL is enabled. Which result should you trust?
Start with the exact address and error, then test from another device and connection. A certificate warning can have a different cause from a missing image or an outdated page. For a business website, the immediate job is to restore normal access to enquiries, bookings and checkout, then establish why the protection failed.
1. Record the warning before changing anything
Ask the person reporting the problem for the full web address, a screenshot showing the error code, the time it happened and their browser. Find out whether they followed an advert, an email, a saved bookmark or a link from another website.
Keep that original link. Testing a shorter address typed into your own browser can miss the route the customer actually used.
Certificate errors mean the browser cannot complete its security checks. Mozilla’s guide to security warning codes explains the distinction between expired certificates, an unknown issuer and a certificate that is not valid for the requested domain.
Do not ask customers to bypass the warning or enter payment details while you investigate. Give them an established alternative contact route if they need to complete an urgent enquiry.
2. Establish whether the fault follows the website, device or network
Use a small comparison that someone else can repeat:
- Open the exact failing address on your usual computer.
- Try it on an updated phone using mobile data, with Wi-Fi switched off.
- Try a second browser and record whether the result changes.
- Check whether unrelated HTTPS websites also fail on the affected device.
These results narrow the investigation; they do not prove a particular cause. If several devices on separate connections fail on the same address, prioritise the website’s hosting and certificate setup. If the failure follows one office network, involve the person managing that network.
Google’s Chrome error guidance identifies incorrect device time as one cause of NET::ERR_CERT_DATE_INVALID. It also explains that workplace HTTPS inspection can produce authority errors when the necessary organisational certificate is missing.
Check the affected device’s date, time and updates. On managed equipment, let IT investigate certificate trust and inspection settings. Avoid changing the public website merely to make one unusual device pass.
3. Check the certificate customers actually receive
Send the failing hostname to your hosting provider or developer. The hostname is the domain part of the address, including any www, shop or booking prefix.
Ask them to inspect the certificate served over the public connection. A certificate listed in a control panel is useful evidence, but it does not establish what every visitor receives.
Check dates and domain coverage
Confirm the certificate is currently valid and covers the exact hostname. Include both the main domain and its www version in the checks, even if one normally redirects to the other. Check separate booking or shop subdomains when they are part of the customer journey.
For example, if an email points customers to a booking subdomain, a successful visit to the homepage does not complete the test. Your developer needs to reproduce that booking address and its onward route.
Check the trust chain
An unexpired certificate can still fail verification. Mozilla’s guidance above notes that an unknown-issuer error can arise when the server does not provide the appropriate intermediate certificates. Ask the host to verify the complete chain, rather than simply confirming that a certificate file exists.
Give the provider the time of the last hosting move, domain change or certificate renewal. Ask them to compare the current deployment with that change, and report the confirmed cause before making several unrelated adjustments.
4. If you use Cloudflare, check both connections
A Cloudflare-protected website has a visitor-facing connection and a separate connection to the hosting server, known as the origin. A valid certificate visible to the visitor does not establish that the origin certificate is valid.
Cloudflare’s Error 526 documentation explains that this error occurs when it cannot validate the origin certificate while Full (strict) mode is in use. Its checks include expiry, hostname coverage and a complete certificate chain.
If customers receive that error, ask the host and whoever manages Cloudflare to check the origin together. Make the repair address the failed validation. Do not treat a reduction in certificate checking as the finished fix.
Record which certificate was replaced and where. That prevents a support conversation ending with “SSL renewed” when the work addressed a different part of the connection.
5. Find out why automatic renewal stopped working
Replacing an expired certificate restores service only if the replacement is deployed correctly. It leaves a second question: why did the expected renewal process fail?
Ask the provider for the last successful renewal, the latest failed attempt and the relevant error. Request a clear answer about who owns the scheduled renewal and who receives failure alerts.
Let’s Encrypt’s challenge documentation explains how it verifies control of a domain. With HTTP-01, the renewal client provides a challenge file that must be reachable on port 80. With DNS-01, it creates a specific DNS TXT record. These are different validation routes, so the investigation must match the method actually configured.
After a hosting migration or DNS-provider change, ask the engineer to verify that this validation route still works. They should check the relevant challenge response and renewal logs, rather than repeatedly requesting replacements without addressing the failure.
Issuing a certificate and installing it are also separate tasks. For installations using Certbot, its official user guide documents automatic renewal, renewal testing and deployment hooks. It also warns that certificates obtained with its manual plugin need authentication hooks to renew automatically.
Ask the engineer to test the configured renewal process and confirm deployment afterwards. A successful test of certificate issuance does not replace checking the certificate served by the live website.
6. Make renewal and monitoring fit the certificate lifetime
There is a timely reason to check custom renewal schedules. Let’s Encrypt’s 14 October 2026 update confirms that its classic profile now issues 64-day certificates in its staging test environment. The same update retains 10 February 2027 as the planned date for that default in production. As of 18 October 2026, that production change is still ahead.
This does not mean every business needs to replace its certificate now. Ask whoever maintains yours whether renewal timing adapts to the certificate’s lifetime, and whether the installation and monitoring processes have been checked.
Do not assume the certificate authority will email you before expiry. Let’s Encrypt confirmed that its expiration notification emails ended on 4 June 2025. Your host may offer its own alerts; establish that explicitly.
Assign a named person to receive renewal failures and external certificate-expiry alerts, with a backup contact. Agree how an alert becomes a support task and how completion is checked.
7. Separate certificate failures from mixed content
If the page opens but particular images, scripts or embedded tools fail, ask the developer to check the browser console for mixed-content errors.
Mozilla’s mixed-content documentation describes an HTTPS page requesting resources over an insecure connection. Browsers upgrade some requests to HTTPS and block others. Renewing the page’s certificate does not correct an insecure resource address.
The repair should update the affected resource or integration to a working HTTPS endpoint, then test the actual feature. Keep this separate from a certificate warning that prevents the page opening at all.
8. Verify the customer journey before closing the incident
Repeat the original failing visit after the repair. Use a computer and a phone on separate connections, without a saved security exception.
- Check the addresses used by adverts, email links and bookmarks, including relevant subdomains.
- Confirm there are no certificate warnings anywhere along the route.
- Complete a clearly identified test enquiry, booking or appropriate checkout test and confirm it reaches the expected destination.
- Ask for confirmation of the certificate now served publicly, the renewal test result and the alert recipient.
If the outage also affected advertising, use our guide to Google Ads destination errors to check the landing route and any remaining review requirements.
Keep a short incident record: the failing address, confirmed cause, repair, verification and responsible person. The next renewal should have a clear owner and a working way to raise a failure.
If you need help tracing the fault across your website, hosting and integrations, contact BuzzBoost. Our web development service covers the technical functionality behind your website, so we can discuss the failing journey and the next practical step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
