An SSL certificate, more precisely a TLS certificate in current use, helps a browser authenticate an HTTPS server and establish an encrypted connection. Check 4 things for a business site: the hostname, certificate validity, renewal operation and insecure resources inside the page. This connection protection does not verify the website’s content or the business’s claims.
Start by listing the public hostnames customers actually use. The main domain, a www address and a separate application address may be served differently. A certificate working at one address does not establish that every other address or page is correctly configured.
How does a certificate become trusted for a domain?
Let’s Encrypt’s ACME explanation describes a client proving domain control to the certificate authority before requesting a certificate. The authority can use a challenge to verify that control. This establishes a technical relationship with the domain; it is not an endorsement of the business operating the website.
Keep the domain-validation process distinct from your organisation’s identity claims. A customer should not be told that an HTTPS connection proves accreditation, financial soundness or the accuracy of an offer. It protects the connection in a particular way, while the business remains responsible for what it publishes and how its application behaves.
| Check area | Question to answer | Evidence to inspect |
|---|---|---|
| Hostname | Is this the address customers actually use? | Certificate and browser behaviour at that hostname |
| Issuance | Can the chosen validation method complete? | Successful authorised challenge and issuance result |
| Validity | Is the served certificate currently valid? | Dates, chain and browser verification |
| Renewal | Who notices and resolves a failed renewal? | Monitored process and a documented owner |
| Page resources | Does HTTPS content still request insecure material? | Browser diagnostics on representative pages |
| Recovery | Can the correct configuration be restored? | Retained configuration and authorised recovery route |
The table is an original operational checklist, not a universal server command sequence. Hosting panels, proxies, content delivery services and application servers can terminate HTTPS in different places. Establish where the public connection is handled before changing certificates on a server that visitors never reach directly.
What can make issuance or renewal fail?
The validation method must match the environment. A domain challenge can depend on the DNS or web response being served correctly. If a proxy, redirect or wrong virtual host interferes, changing unrelated application files will not solve the underlying issue. Follow the chosen authority’s current documentation for the actual validation method.
Record which component requests and installs the certificate. It may be a hosting panel, an ACME client or another managed service. Avoid running several competing renewal mechanisms without understanding which one controls the served files. An unused certificate renewed elsewhere does not protect the live hostname.
Treat automation as a process to observe. Let’s Encrypt describes automated certificate acquisition through ACME, but a particular installation still needs working validation and deployment. Establish where failures are recorded, who receives the signal and how the served certificate is checked after a change.
Do not publish a generic renewal interval as if it applies permanently to every authority and certificate type. Use the certificate’s actual validity information and the current client’s recommended operation. The meaningful business requirement is that renewal failures are detected and corrected before they interrupt customers.
Why can a site have a certificate and still contain mixed content?
MDN’s mixed-content guide explains the problem of an HTTPS page loading resources through an insecure protocol. The main page can be securely delivered while a resource request introduces a different risk. Inspect the whole page, including images, scripts and other dependencies, instead of stopping after seeing HTTPS in the address bar.
A page builder, old content link or third-party resource can retain an HTTP address after the main site moves to HTTPS. Identify the actual request in browser diagnostics and fix the relevant source. Blindly replacing every occurrence of a string can damage unrelated content or miss resources generated by an integration.
Distinguish mixed content from mixed downloads. MDN describes insecure downloads initiated from a secure context as a related concern. A document link can therefore need attention even when the surrounding page renders normally. Check the actual destination and delivery protocol for important customer files.
Do not rely on browser upgrading or blocking as the complete repair. Those behaviours can vary by resource and browser, and a blocked request can break functionality. Test the result after fixing the source, including any feature that depended on the affected resource.
How do you verify the site after a certificate change?
Use this original hostname-to-resource test sheet with representative pages and clearly labelled non-sensitive test activity.
| Scenario | Test | What a failure means |
|---|---|---|
| Main address | Open the canonical hostname directly | The public HTTPS route needs investigation |
| Alternate address | Open each intended alias | Alias routing or certificate coverage may differ |
| Deep page | Open a service or application URL directly | Homepage success is not sufficient evidence |
| Resource loading | Inspect browser security and network diagnostics | An insecure or blocked dependency may remain |
| Download | Follow an important public document link | File delivery may differ from page delivery |
| Form or transaction | Complete the approved test workflow | HTTPS alone does not establish application function |
| Renewal ownership | Locate the responsible process and operator | An expiry risk may be unowned |
| Rollback readiness | Review retained configuration and recovery steps | A failed change may be difficult to reverse |
A failure is a starting point for diagnosis, not permission to make unrelated changes on production infrastructure. Preserve the current configuration and follow the site’s authorised change process. Shared hosting can serve several sites, so an apparently small certificate change can affect a wider configuration if applied carelessly.
Retain evidence of the actual hostname and time tested. A certificate inspection performed before a DNS or proxy change may no longer describe what customers receive. Recheck the public route after the relevant infrastructure changes, with attention to the served chain and application behaviour.
For the broader operating responsibility, see hosting. To explain an HTTPS problem, get started with the affected public address and a description of the browser message, without sending private keys or account credentials.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.