Your business website says “Not secure”. Start by saving the exact message and the address where it appears. A page using HTTP, an invalid certificate, a blocked resource and a browser warning about a dangerous website need different investigations. Buying another certificate before identifying the warning can leave the original problem untouched.
This guide helps a business owner prepare a useful repair request and check the result. It does not establish that a site is free of malware or replace an investigation when a browser flags dangerous content.
Save the warning before changing anything
Record the full address, including http:// or https://, whether it includes www, the affected page, the browser and the time. Save a screenshot and any error code. Say whether the page opens, whether images are missing and whether the warning appears before you can reach the site.
Avoid entering customer information or payment details while the connection is in doubt. Do not ask customers to dismiss the warning so they can enquire. Chrome's connection guidance explains the difference between a private connection, an insecure connection and a dangerous-site warning.
My suggested first message to the maintainer is simple: “This exact address shows this message on this device. Please identify the cause, the affected addresses and how you will prove the repair.” Keep account passwords out of screenshots and ordinary support messages.
Match the symptom to the investigation
The table below is a triage worksheet, not a diagnosis. Browser wording changes; send the actual message rather than trying to force it into a category.
| What you observe | What to ask the maintainer to investigate | Evidence to request |
|---|---|---|
| An HTTP address opens without a private connection | HTTPS availability and how old HTTP links reach the intended secure page | The original address and final address after the repair |
| HTTPS shows a certificate warning | Certificate validity, the name it covers and the certificate chain served to visitors | Exact error code, affected hostname and corrected public result |
| The page opens but an image or feature fails | Whether the page loads insecure resources | A list of affected resources and a clean repeat of the failed action |
| A full-page dangerous-site warning appears | The browser's security finding and the site's possible compromise | Investigation findings and the relevant review or recovery process |
Mozilla documents certificate warning codes, including name and trust problems. A certificate for one hostname does not automatically prove that every address customers use is covered. Ask about the specific address that failed.
An HTTPS page can also request resources over HTTP. Browsers upgrade some mixed content and block other requests; the result depends on the resource. The maintainer should inspect the browser console and actual requests. MDN's mixed-content documentation explains this behaviour. A newly issued certificate alone does not rewrite those resource addresses.
Check whether the problem follows the site
Repeat the same address on another current browser or device and, where practical, another trusted network. Keep the address identical. A working homepage and a failing contact page are different observations.
If one device fails while the others work, record that difference. Check its date, time and time zone. Network settings, proxies or software that intercepts connections can also affect the result; Mozilla's secure-connection guide describes these possibilities. Ask whoever manages the device or network to investigate rather than disabling protection as a permanent workaround.
These comparisons narrow the investigation. They do not prove that all customers can reach the site. If the warning repeats across devices, give the maintainer those results instead of sending only “it works on my laptop”.
Agree on the repair and its acceptance evidence
Before approving work, ask who manages the certificate and its renewal: the hosting provider, website platform or your maintainer. Let's Encrypt's getting-started guide makes this distinction explicit. Some providers manage certificates automatically; others require a setting or a separate client. Confirm your actual arrangement instead of assuming issuance means ongoing management is covered.
For a connection repair, I would request these checks:
- Reopen each address that originally failed, without bypassing a browser warning.
- Confirm that old HTTP links reach the intended HTTPS page, preserving relevant paths.
- Check the hostnames customers actually use, including
wwwif it is advertised or linked. - Repeat the failed action on desktop and phone: open the image, download the document or use the enquiry route.
- Record the cause, repair date, responsible person and future renewal or monitoring arrangement.
Use an authorised test enquiry and confirm its receipt; avoid sending customer data. If the connection warning is gone but the enquiry still disappears, continue with the separate contact-form delivery checks. Record unresolved items rather than closing the whole job because one page now opens.
Know what a clean connection result establishes
HTTPS protects information in transit between the browser and the site. It does not establish that your product claims are accurate, your business is trustworthy or every part of the website is secure. A dangerous-site warning needs its own investigation even if the site also has a valid certificate.
For the business record, keep a short before-and-after note: affected addresses, exact message, cause, repair and repeat-test results. Link it to your website maintenance responsibilities. That gives the next person something concrete to act on if the problem returns, without turning a connection repair into a claim that the entire website has passed a security audit.
