A customer opens your website and sees “Your connection is not private.” Even if the site worked yesterday and the hosting invoice is paid, treat that warning as a real service incident. Do not ask the customer to click through it. The safest first move is to capture the exact warning, contact the company that manages the website, and verify the certificate the public server is actually presenting.
Chrome says this full-page message can reflect a problem with the site, the network, or the visitor’s device; Chrome also explains that website certificates authenticate and secure the HTTPS connection between a site and a browser.[1] That is why one screenshot is useful evidence, but not a complete diagnosis.
The problem in plain English
A public website normally presents a TLS certificate for the hostname a visitor requested. A privacy warning may appear when that certificate is expired, does not cover the requested hostname, has an untrusted or incomplete chain, or when the visitor’s device or network interferes with validation.[1] Renewing a certificate and deploying it are separate steps: a control panel can show a newly issued certificate while the public website still serves the old one.[5]
Certificate automation deserves attention in 2026. The CA/Browser Forum Baseline Requirements list a 200-day maximum validity period for publicly trusted subscriber certificates effective March 15, 2026.[2] This is a maximum, not a promise that every certificate lasts 200 days: some issuers use shorter periods, and an annual purchase or subscription can still require one or more certificate reissues during its term.
Let’s Encrypt says shorter certificate lifetimes limit the useful period of a mis-issued certificate or compromised key and encourage automation, which it describes as essential for reliability.[3] Practical takeaway: do not manage renewal from memory or rely only on a calendar reminder; test the automated path and independently monitor the certificate served to visitors.
Who is affected—and who may not be
Likely affected
- Visitors who receive the warning on more than one current device or network.
- The exact hostname that fails, such as
example.com,www.example.com,shop.example.com, or a customer portal. - Forms, checkout, booking, login, API, and embedded services reached through the affected hostname.
- Sites whose certificate was renewed but not attached to every active load balancer, CDN edge, proxy, or origin.
Possibly not affected
- Other hostnames covered by a different certificate and tested separately.
- Visitors whose current browser shows a valid secure connection while one device with a wrong clock, stale software, antivirus interception, captive portal, or managed-network policy shows the warning.
- Your domain registration itself. A paid domain renewal and a valid TLS certificate solve different problems. See our domain-renewal safety check and domain-name safety audit for registrar, DNS, ownership, and recovery checks.
Do not declare the incident fixed because one browser works. Test every public hostname your customers use, from an independent connection, after the change.
First-response checklist for a managed-hosting owner
- Do not bypass the warning or enter information.[1] Tell customers and staff to stop at the warning, close the tab, and use a known phone number or another established channel if they must reach you.
- Record the evidence. Save the exact URL, time, browser, error code, and a screenshot that excludes passwords, customer records, payment details, and private tabs.
- Try one independent check. Use a current browser on a second device and a different connection, such as cellular data instead of office Wi-Fi. Do not sign in or submit a form.
- List every customer-facing hostname. Include the bare domain,
www, store, booking, portal, and any hostname linked from ads or email. - Open a high-priority host ticket. Ask the provider to confirm the hostname, expiration date, issuer, covered names, full chain, renewal status, deployment target, and the certificate currently served from the public edge.
- Pause risky activity. Avoid DNS, CDN, proxy, or origin changes while the host investigates unless the responsible administrator has a documented change and rollback plan.
Exact managed-hosting diagnostic and repair workflow
Step 1: Separate a visitor-only problem from a public-site problem
Compare the exact same HTTPS URL on two current devices and two networks. If only one device fails, check its date, time, time zone, operating-system updates, browser updates, captive-portal state, security software, and organization policy. If several independent checks fail, treat the website path as the leading suspect. Do not “fix” a device by installing a certificate offered by an unexpected page or disabling security inspection.
Step 2: Read the warning without proceeding
Record the browser’s exact code and wording. Codes vary, but the useful distinction is whether the browser reports an expired certificate, a name mismatch, an unknown issuer or chain problem, or a local clock/network condition. Send the unedited code to the host; do not translate every warning into “expired certificate.”
Step 3: Verify the live certificate, not just the billing screen
In the browser’s certificate viewer or the hosting provider’s public TLS checker, inspect the certificate served for each hostname. Record the “valid from” and “valid to” times, issuer, and the names covered by the certificate. The requested hostname must match a covered name; checking only the expiration date can miss a name mismatch.
Step 4: Compare issuance with deployment
Ask: “Was a replacement certificate issued?” and separately: “Which certificate is the public endpoint serving now?” If a new certificate exists in the account but the old serial number or old expiration date remains visible publicly, deployment or service reload is incomplete. If the site uses a CDN or load balancer, identify whether TLS ends there rather than at the hosting origin.
Step 5: Identify why automated validation failed
For the common HTTP-01 method, Let’s Encrypt says the ACME client places a token under /.well-known/acme-challenge/, and the validation service retrieves it over HTTP; redirects are limited to HTTP or HTTPS on ports 80 or 443.[4] Ask the host whether redirects, a firewall, CDN rules, a maintenance page, a changed web root, or blocked port 80 prevented that file from being reached.
For DNS-based validation, ask whether the required TXT record was created at the authoritative DNS provider and whether an old or incorrect record remained. Let’s Encrypt notes that DNS-01 can issue wildcard certificates and can work where web servers are not exposed publicly, but it requires safe DNS automation and propagation awareness.[4] Do not email DNS API credentials or paste them into a support chat.
Step 6: Let the responsible provider renew and deploy
On managed hosting, use the provider’s documented “renew,” “reissue,” or “repair certificate” workflow, or authorize its support team to do so. Confirm that the requested certificate includes every intended hostname and that the provider deploys the complete chain to the endpoint that actually handles public HTTPS. Avoid deleting certificates, changing nameservers, disabling the CDN, or forcing repeated issuance attempts without the provider’s direction.
Step 7: Prove the repair from outside
After deployment, open a fresh private-browsing window on a different network and test each listed hostname. Reopen the certificate details and confirm the expected new validity period and covered names. Then test a harmless public page and the start of essential workflows without entering real payment or customer data. Keep the ticket open if any hostname, redirect destination, IPv6 path, CDN edge, or secondary endpoint still serves the wrong certificate.
Step 8: Prevent the next surprise
Enable the host’s renewal notices, verify that the account email reaches more than one responsible person, and add independent checks well before expiration. A practical schedule is 30, 14, and 7 days before expiry, but monitoring thresholds are operational guidance—not a guarantee that renewal or deployment will succeed.[3] Retest after DNS, CDN, proxy, web-root, firewall, or hosting migrations.
Self-managed server administrators only
This section is not for a business owner who has managed hosting. If you do not administer the web server, ACME client, DNS, and deployment path, stop and send the evidence to the provider. The wrong live command can interrupt HTTPS or trigger certificate-authority rate limits.[5]
- Map the TLS termination point. Document whether the certificate is served by Nginx, Apache, a reverse proxy, a container ingress, a cloud load balancer, or a CDN. Do not assume the origin is public.
- Inspect without changing state. Use your platform’s certificate viewer or a read-only TLS inspection tool to record the live chain, names, serial number, and validity times for each hostname and each address family.
- Review the ACME client and scheduler. Certbot’s documentation says Linux and BSD administrators can look for
certbot renewin cron or in systemd timers, and it documentscertbot renew --dry-runfor testing future renewal.[5] Use the syntax and service-management procedure that match your installed version and operating system. - Run a staging or dry-run test first. Capture the exact failure before changing firewall, DNS, web-root, plugin, or credential settings. Correct only the identified cause.
- Renew through the existing supported configuration. Do not invent a new authenticator, expose a private service, or replace working DNS credentials during an outage unless the documented recovery plan requires it.
- Deploy and reload safely. Validate the server configuration before reload, preserve rollback material, and follow the operating system or platform documentation. A successful issuance is not proof of successful deployment.[5]
- Verify externally. Confirm the newly served serial number, chain, covered names, and expiration time from outside the server network. Repeat for every endpoint and configure independent expiry monitoring.
Stop conditions and cautions
- Stop immediately if a page asks you to install a certificate, profile, browser extension, or remote-support tool before viewing the site.
- Stop and escalate if the hostname resolves to an unexpected provider, the certificate names an unfamiliar organization, or account ownership is disputed.
- Stop repeated renewal attempts after the same validation failure; preserve logs and correct the cause rather than hammering the certificate authority.
- Do not disable HTTPS, certificate checking, HSTS, a firewall, or a CDN as a shortcut. These changes can create a larger security or availability problem.
- Do not share private keys, DNS API tokens, hosting passwords, or customer data.[4] A legitimate support workflow should provide a controlled account or secure authorization path.
- Escalate urgent commerce impact. If checkout, payments, healthcare, legal, or customer portals are involved, pause affected campaigns or workflows through authorized business channels until HTTPS is verified.[1]
Good and bad response examples
Good customer message
“We are investigating a certificate warning on our website. Please do not bypass the warning or enter information. Use our known phone number if you need immediate help. We will confirm when independent checks show the secure connection is restored.”
Bad customer message
“The site is safe—click Advanced and continue. It is only an expired certificate.”
Why it is bad: the warning’s cause has not been proved, the visitor is asked to defeat a security control, and “safe” overstates what the business knows.
Good host ticket
“At 1:05 p.m. EDT, current Chrome and Firefox on two networks showed a certificate warning for https://www.example.com, while https://example.com loaded normally. Please confirm the live certificate’s covered names, validity, chain, renewal result, and deployment target. Screenshot and browser error code are attached with private data removed.”
Bad administrator response
“I clicked renew several times, deleted the old certificate, turned off the CDN, and changed DNS. Now we wait.”
Why it is bad: several variables changed at once, rollback became harder, and there is still no proof of what the public endpoint serves.
Frequently asked questions
Is renewing the domain the same as renewing the TLS certificate?
No. The domain registration preserves control of the name; DNS points that name toward services; the TLS certificate helps authenticate and encrypt the HTTPS connection.[1][7][8] All three can have different providers, accounts, and failure modes.
Can I tell customers to click through temporarily?
No. You cannot safely prove from the warning page alone that the visitor reached your intended server.[1] Give customers another established contact or transaction channel until the secure connection is verified.
The hosting panel says “active.” Is that enough?
No. “Active” may describe a product, an order, or a certificate stored in the panel. Verify the certificate actually served for every public hostname and endpoint.
Why does the bare domain work while www fails?
They are separate hostnames. They may resolve differently, terminate TLS on different systems, or not both appear in the certificate’s covered names.[4] Test and repair each one.
Why did auto-renewal fail after a migration?
Common migration suspects include a changed web root, a new proxy or CDN rule, blocked challenge traffic, moved authoritative DNS, missing API credentials, an inactive scheduler, or a deployment hook that still targets the old service.[4][5] Logs and a dry-run should identify the actual cause before you change anything.
Does the 200-day maximum mean my certificate lasts 200 days?
No. The 200-day figure is an industry maximum effective March 15, 2026, not a minimum or a universal product term.[2] For example, DigiCert documents that it began issuing public TLS certificates with a 199-day maximum on February 24, 2026.[6] Check the validity dates of the certificate actually issued and served.
Need help?
If your business website is showing a privacy warning and you are not sure who controls the domain, DNS, host, CDN, or certificate, contact The IT Guys. Bring the exact URL, screenshot, browser error code, and provider names—but never send passwords or private keys.
Sources
- Google Chrome Help: Check if a site’s connection is secure (accessed September 24, 2026).
- CA/Browser Forum: Latest Baseline Requirements, version 2.3.0 (accessed September 24, 2026).
- Let’s Encrypt: Certificate Lifetime Rationale and Plans (accessed September 24, 2026).
- Let’s Encrypt: Challenge Types (accessed September 24, 2026).
- Certbot 5.8.0 documentation: Renewing certificates (accessed September 24, 2026).
- DigiCert: End of 397-day public TLS/SSL certificates (accessed September 24, 2026).
- The IT Guys: Stop a Domain Renewal Mistake From Taking Down Your Website and Email (accessed September 24, 2026).
- The IT Guys: Run This Domain-Name Safety Audit (accessed September 24, 2026).