How to verify certificate installation correctly

Do not verify an SSL installation by looking for a website seal or by checking that the browser no longer shows a warning on one computer. Verify the TLS connection presented by the actual public hostname.

The checks that matter

Visit https://your-domain.example on a clean browser session. Confirm there is no certificate-name, expiry or trust warning.
Inspect the certificate's Subject Alternative Name (SAN) list. It must cover the hostname you requested, including www if your site uses it.
Confirm the certificate is within its validity interval and the server sends a complete, trusted chain to an appropriate public root.
Test whether the site redirects HTTP traffic to HTTPS as intended and does not load insecure assets ("mixed content").
If your service has several IPs, load balancers, CDN edges or IPv6 endpoints, test each relevant route; one server may still have an old certificate.

Command-line check

openssl s_client -connect example.com:443 -servername example.com \

-verify_hostname example.com -verify_return_error -showcerts

Replace example.com with your hostname. Check the hostname-verification and certificate-chain result; the -verify_hostname option is important because displaying the chain alone does not validate the requested hostname. These flags rely on the local OpenSSL trust store. Inspect any missing intermediates. For a hostname/path overview, you can also use a reputable external TLS diagnostic service, but do not send credentials or customer data.

Common problems

Name mismatch

Missing or incorrect SAN / wrong virtual host

Expired certificate

Replacement not deployed everywhere

Untrusted issuer

Missing chain or private CA used unintentionally

Old certificate after update

CDN cache/configuration, SNI or load balancer node

HTTPS page loads with warning

Mixed HTTP assets or insecure embedded content

A certificate "trust badge" is optional marketing UI; it is not required for successful TLS deployment. If something fails, give NiceNIC Support the hostname, UTC test time, observed certificate dates and non-sensitive error text—not your private key.

Verify every advertised hostname, not just one URL

A company may serve example.com, www.example.com, shop.example.com and api.example.com from different TLS endpoints. Test each hostname's actual live certificate: SAN coverage, trusted chain, issuance/expiry and HTTP-to-HTTPS behavior. A certificate valid on www does not prove the API hostname is safe.

Use the OpenSSL hostname-verification command shown above or an external TLS test for each hostname. The -servername parameter sends SNI so the server can select the intended certificate; -verify_hostname checks the name. Replace both arguments with the exact live hostname. Examine exit status, validation output and the certificate dates, then test on a second network if practical.

Three common failures

Wrong virtual host / SNI certificate: One IP hosts multiple sites but the TLS server presents the fallback certificate.
Incomplete intermediate chain: The leaf certificate is correctly issued, but some clients cannot chain it to a trusted root.
Old deployment still active: One CDN edge, IPv6 service or load-balancer node still serves an expired certificate while other routes work.

For customer support, record the hostname, resolved IP or CDN endpoint, test time and error; never attach the private key.