What Is an SSL Certificate and How Do You Check It?
An SSL certificate, more accurately a TLS certificate, helps a browser verify a hostname and encrypt a connection.
How it works
Certificates include a subject, issuer, subject alternative names, validity dates, fingerprint, negotiated TLS version, and cipher. A hostname mismatch or expiry can break trust, while CDN and load-balancer deployments can present different certificates by route.
SSL is the familiar name; TLS is the current protocol
People still say SSL certificate, but modern browsers use TLS. A TLS certificate helps a client verify that the server presenting it controls a hostname, then supports encryption for the connection. It is an important transport-security component, not a statement that a website's content, owner, or business is trustworthy.
The certificate includes a subject and issuer, validity dates, and subject alternative names (SANs). Browsers primarily use SANs for hostname matching. If a visitor opens www.example.com but the certificate only names example.com, the browser can show a hostname mismatch even though a TLS connection was technically established.
The SHA-256 fingerprint is a compact identifier for the exact certificate. It is useful when comparing a deployed certificate with an expected one, but a fingerprint by itself does not explain whether the hostname, expiry, or chain is correct.
Dates, chains, protocols, and ciphers
A certificate is valid only within its not-before and not-after dates. An expired certificate commonly causes browser warnings and service failures; a certificate that is not yet valid can do the same. Renewal should happen before expiry and be checked on the public endpoint after deployment.
Browsers also validate a chain from the site certificate through intermediate certificates to a trusted root. An incomplete chain can work in one environment that has a cached intermediate but fail for new clients. The negotiated TLS protocol and cipher describe the connection selected by this server and client at that moment; they can vary with the client, port, and server configuration.
CDNs, load balancers, and SNI make context important. A shared IP can serve different certificates depending on the requested hostname. A nonstandard port can present another service entirely. Test the exact hostname and port users reach rather than assuming the IP's default certificate represents every route.
Common certificate failures
An expired certificate, a SAN hostname mismatch, an incomplete chain, and a wrong certificate selected by SNI are common causes of TLS warnings. DNS changes can direct users to an older edge, while a load balancer can retain an old certificate on one backend. Compare the presented subject, SANs, issuer, dates, and fingerprint across the affected route.
Start by checking the public hostname without credentials or private paths. Confirm its DNS resolution, then inspect the certificate and redirect behavior. If only some locations fail, review CDN or load-balancer deployment state. Do not solve a mismatch by training users to bypass browser warnings; correct the hostname or certificate deployment.
A valid certificate does not prove a page is benign, correctly configured, or free of vulnerabilities. It says that this connection passed limited TLS identity and encryption checks. Application security, content safety, account protection, and HTTP policy require separate review.
Using the SSL Certificate Checker
Our checker makes a bounded TLS connection to a public target and shows the certificate presented on that path, including issuer, subject, SANs, dates, SHA-256 fingerprint, protocol, and cipher when available. It is useful for deployment troubleshooting and does not log in, submit data, or test private addresses.
Use its result as a point-in-time observation. Follow with an HTTP Headers check when redirects or browser policies matter, a DNS lookup when the hostname resolves unexpectedly, or a port check when a service uses a public nonstandard port.
For a renewal problem, compare the certificate fingerprint and expiry presented by the public hostname with the certificate you expected to deploy. If the browser still sees an older certificate, examine the CDN, load balancer, and all listening endpoints rather than repeatedly issuing new certificates. If the certificate is correct but a warning remains, read the exact browser error: a hostname mismatch, an untrusted chain, and an expired certificate require different fixes. The safe outcome is a correct deployment, not a browser exception.
Practical guidance
- Check that the exact hostname appears in the certificate SANs.
- Review expiry and the deployed certificate before a planned renewal window.
- Use HTTP headers and DNS checks for surrounding deployment context.
Common question
Does a valid certificate prove a website is safe? No. It proves a limited transport identity and encryption condition, not the trustworthiness of content.