How TLS certificates work

A TLS certificate binds a public key to a domain name that a certificate authority already trusts. Your browser checks the name, the validity dates, and the chain back to a root it already knows. The server must also prove it holds the matching private key. When those checks pass, the connection is encrypted. A padlock means encryption to that name, not that the site itself is honest or safe.

Name and date checks come first

If the certificate covers example.com and you open www.example.com, many browsers show a warning. That is a name mismatch, not a dead certificate. AutoSSL can issue both names when public DNS for each name points here and port 80 answers on each host. When www points at a CDN and the apex points here, you often end up with two different certificates and two different results. Read the subject on the live certificate rather than assuming one padlock covers every hostname.

Expiry is the next common cause. An expired leaf certificate fails until a new one is issued. AutoSSL renews ahead of time when HTTP-01 validation can still reach the vhost. If validation cannot reach the site, you usually notice the morning the old certificate expires. Rebooting a VPS does not create a new certificate by itself.

Why one device warns and another does not

Browsers need the leaf certificate plus the intermediate certificates up to a root they already trust. Serving only the leaf can work on a machine that cached the intermediate earlier and fail on a fresh phone. Tickets that say “only Android fails” often point to a missing intermediate. cPanel with AutoSSL normally sends a full chain. A PFX file imported by hand often does not.

Check what the server actually presents

This command prints the leaf certificate used in the handshake:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject

The subject must match the name in the address bar, including www when that is what you typed. The issuer should look like Let’s Encrypt or the CA you purchased from. The notBefore and notAfter values should include today. If the subject shows the shared server hostname or another account’s domain, you are hitting the default vhost because SNI did not send the name you expect. Run the same command again with -servername set to the host you actually visit.

When the dates look fine, the name matches, and phones still fail, the chain is the remaining suspect. AutoSSL and Let’s Encrypt on cPanel is the process that should keep both the leaf and the chain current on shared hosting.