SSL certificate is not trusted by browsers

SeverityCritical

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_cert_invalid

Short answer

A client connecting to your site cannot verify the certificate, so visitors get a full-page security warning instead of your page. The usual causes are a certificate issued for a different name, a self-signed or expired certificate, or a server that sends only its own certificate without the intermediate chain. Install a certificate from a public certificate authority that names this exact hostname, and serve the full chain.

Why it matters

Every visitor hits an interstitial such as NET::ERR_CERT_COMMON_NAME_INVALID or SEC_ERROR_UNKNOWN_ISSUER. Few click through, and forms, checkout, apps and API clients refuse to connect at all. This affects search as well: Google indexes the HTTPS version of a page by default only when it has a valid certificate, and people arriving from results see the warning before your content.

An incomplete chain is the trickiest variant. Some browsers repair it by downloading or remembering the missing intermediate, so the site looks fine on your own computer, while other browsers, many apps, command-line tools and crawlers fail. A clean result in your own browser is not proof.

How Glimana detects it

Glimana makes a strictly verified TLS connection to your hostname on port 443, using a standard store of publicly trusted root certificates. It does not fetch missing intermediates, so your server must send the complete chain itself. It then checks that your hostname appears in the certificate's Subject Alternative Names; a wildcard covers exactly one label (*.example.com matches www.example.com, but not example.com or a.b.example.com). If verification or the name check fails, the result is critical, and the problem shows the error together with the names the certificate does cover. An expired certificate fails here as well as in the expiry check.

How to fix it

Watch out

Behind Cloudflare, check the record's proxy status first: a grey-cloud (DNS only) record sends visitors straight to your origin's certificate, and Universal SSL covers only the root domain and first-level subdomains (www.example.com, not dev.www.example.com). Cloudflare Origin CA certificates are trusted only by Cloudflare; on a server that visitors reach directly they fail exactly like a self-signed certificate.

Find the finding in Glimana. Open Security; this check is in the Certificate and HTTPS group, with the evidence from the last scan under its title. The same problem is listed under Issues › SSL certificate is not trusted by browsers.
Apply the fix on your platform.

cPanel / PleskCloudflareApache / Nginx

cPanel: Security › SSL/TLS Status shows which names are covered. Select every hostname you serve (both example.com and www.example.com) and click Run AutoSSL. For a manually installed certificate, open SSL/TLS › Manage SSL sites and paste the intermediate certificates your CA supplied into Certificate Authority Bundle. Plesk: issue a new Let's Encrypt certificate with SSL It! and include the www subdomain.

In DNS › Records, make sure the hostname is proxied (orange cloud) so visitors get Cloudflare's edge certificate. Deeper subdomains need an advanced certificate or Total TLS (SSL/TLS › Edge Certificates; both require Advanced Certificate Manager). Between Cloudflare and your server, use Full (strict) with a valid origin certificate; a Cloudflare Origin CA certificate is fine there.

Point the server at the full chain, not the leaf certificate alone; with Certbot that is fullchain.pem.
Nginx: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; and ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
Apache 2.4.8 or later: SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem and SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
To issue a certificate that covers both names: sudo certbot --nginx -d example.com -d www.example.com (or --apache). Check from any machine: openssl s_client -connect example.com:443 -servername example.com </dev/null | grep "Verify return code" should print 0 (ok).
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

Press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes when the check passes.