Why does the site still show as insecure after installing an SSL certificate?

After installing an SSL certificate, if the browser still displays “Connection is not secure,” “Certificate invalid,” or no padlock icon appears in the address bar, the issue is usually not that the certificate file itself has expired. Instead, it is often caused by an incomplete deployment chain, a mismatch in the accessed domain name, pages still loading HTTP resources, or HTTPS not being properly enabled on the server. Such issues can affect visitors’ trust in the website and may also cause browsers to block or warn about login, form submission, payment redirects, and other processes.

When troubleshooting, do not only check whether “the certificate has been purchased or uploaded.” Use the certificate actually accessed by the browser, the access path, and page resources as the basis: first confirm the error type, then verify the domain name, certificate chain, ports, and redirect rules, and finally address mixed content. This avoids repeatedly replacing certificates without resolving the issue.

Check the browser message first to identify which layer the issue is in

Click the “Not secure” notice or padlock icon in the browser address bar to view the certificate details and specific error message. Different symptoms indicate different troubleshooting directions.

The browser console is also important. If “Mixed Content” appears in the console, it means the main page has been opened through HTTPS, but some resources are still requested through HTTP. If it shows a certificate name error or certificate chain validation failure, return to the server deployment layer for inspection.

Domain name mismatch is the most easily overlooked issue after SSL certificate installation

A certificate is valid only for the domain names listed in it and does not automatically cover all variations. For example, if a certificate is issued only for www.example.com, directly accessing example.com may still cause an error. A standard single-domain certificate issued for the primary domain also usually cannot cover subdomains such as shop.example.com and en.example.com.

Check the “Subject Alternative Name (SAN)” or “Subject Alternative Name” in the certificate details, and compare each item with the actual access entry point. At a minimum, confirm the following:

• Whether both the domain name with www and without www are covered, or whether redirects have been standardized;
• Whether multilingual sites, store sub-sites, download sites, admin backends, and similar services use independent subdomains;
• Whether users may directly access the site through an old domain name, test domain name, or IP address;
• Whether the certificate is deployed in the domain binding or virtual host configuration currently serving external traffic.

Do not attempt to conceal a name mismatch by “redirecting all domains to HTTPS.” Redirection occurs after the TLS handshake, and the browser must first validate the certificate for the current domain. If the certificate name does not match, a warning will still appear first. The correct approach is to extend certificate coverage for actual entry points, or standardize domain names at the DNS, site entry, and promotional link levels.

When the certificate chain is missing, the server may appear properly configured, but clients cannot validate it

An SSL certificate usually consists of more than just one server certificate. The browser also needs intermediate certificates to establish a validation path to a trusted root certificate. If only the domain certificate is uploaded during deployment and the intermediate certificate bundle provided by the CA is not configured, some browsers or older devices may indicate that the certificate is untrusted.

In an Nginx environment, a common issue is that ssl_certificate points to a separate certificate file rather than a full chain file containing both the server certificate and intermediate certificates. For Apache, confirm that the corresponding certificate chain configuration complies with the requirements of the current version. In a control panel environment, use the “complete certificate chain,” “fullchain,” or “CA Bundle” file provided by the certificate authority instead of pasting only the first certificate block.

Also prevent incorrect chain ordering. Normally, the site certificate should be placed first, followed by the intermediate certificates in sequence; the root certificate generally does not need to be actively delivered by the server. After replacing files, reload the Web service configuration and verify again from an external network instead of only checking whether the files exist on the server itself.

HTTPS is enabled, so why does the page still display as insecure?

This situation is often related to mixed content. The page HTML is transmitted through HTTPS, but images, JavaScript, CSS, videos, fonts, analytics code, iframes, or API addresses are still written as http://. Modern browsers directly block some active content, such as scripts and XHR requests. For some images or media resources, they may allow loading but reduce the security status.

Start with the page source code and browser console, identify the specific resource addresses, and then check the resource sources in the following order:

1. Static resources on the site should be changed to HTTPS absolute URLs or use relative paths appropriate for the current site;
2. Hard-coded HTTP links in templates, rich-text content, product details, and historical articles should be checked in batches;
3. Third-party scripts, maps, customer service widgets, embedded videos, and form components must be confirmed to support HTTPS;
4. API domains, file storage domains, and image CDNs should also deploy valid certificates; changing only the homepage domain is not sufficient;
5. After modification, clear site cache, CDN cache, and browser cache, then retest.

It is not recommended to rely solely on the browser’s “automatically upgrade insecure requests” policy. It can serve as a temporary measure, but it cannot ensure that all resources load correctly. If third-party resources do not support HTTPS, it may still result in missing styles, malfunctioning features, or failed data requests.

Check server listening, redirects, and multi-node configurations

Having the correct certificate does not mean that port 443 is already handled by the correct site. Confirm that the server firewall, security group, and Web service all allow access to port 443, and that this port is bound to the certificate corresponding to the target domain. In shared IP and multi-site environments, abnormal SNI configuration may cause the server to return another site’s certificate, resulting in a domain name mismatch.

Redirects from HTTP to HTTPS should also be checked. Ideally, after accessing the http:// version, users should be redirected to the canonical HTTPS address through a single 301 or 308 redirect. Avoid loops where HTTP redirects to HTTPS and HTTPS redirects back to HTTP, and do not allow different pages to repeatedly redirect between versions with and without www. Login pages, form submission pages, payment callback pages, and admin entry points should be verified separately in particular.

If the website uses a CDN, load balancer, or reverse proxy, also confirm the edge-node certificates and origin-server certificates separately. If edge nodes are normal but the origin server has an issue, some origin-fetch scenarios may fail. If the origin server has been updated but the CDN still retains an old certificate, external visitors may not see the new certificate either. Where both IPv4 and IPv6 resolution are used, the nodes corresponding to both address types should be tested.

Avoid recurring issues where an error appears again immediately after renewal

If an old certificate is still shown after renewal, the cause is often that the configured reference path was not updated, the service was not reloaded, or a node did not synchronize the new file. When creating certificate change records, also record the domains covered by the certificate, expiration date, private key storage location, complete chain file location, deployment nodes, and reload operations. Check the serial number and validity period from the external network both before and after updating to confirm that the browser is actually receiving the new certificate.

For marketing landing pages, standalone websites, and multilingual pages, HTTPS checks should also be incorporated into the release process: check external resource protocols before new pages go live, confirm whether newly added subdomains are included in the certificate, and verify the embed code of newly integrated third-party tools. This helps control “Not secure” warnings before release rather than fixing them one by one after receiving visitor feedback.