How to Check an SSL Certificate and Understand Certificate Chain Errors

What an SSL certificate check tells you

“SSL certificate” remains the familiar name, although modern HTTPS uses TLS. TLS protects data in transit and authenticates the server through certificate verification. It does not establish whether the business behind a website is honest or whether the application has security vulnerabilities.¹

In a PeerPeek report, start with four separate results:

Unknown means the checker could not establish the result; Not applicable is not a pass. Certificate details appear only when a leaf certificate is available.

Reading the results separately prevents a common mistake: treating “certificate received” as “certificate trusted.” A server can present a certificate that fails one or more of the other checks.

How to check a website's certificate

Open PeerPeek SSL Checker, enter a public hostname or an HTTPS URL, and select Check certificate. Only the hostname on port 443 is checked: a URL's path, query and fragment are discarded, and no HTTP page or redirect is fetched. HTTP URLs, credentials, IP addresses, private destinations and ports other than 443 are not supported. Start with the exact hostname visitors use, such as www.example.com, rather than assuming that checking example.com covers both.

Read the check time and the four results above. Then use the certificate details to investigate the failed check. After changing a server configuration, submit the hostname again and inspect the recorded check time. The checker can reuse a completed result for up to one hour (up to 60 seconds for an unable-to-complete result). If it says Reused cached result, it is still the earlier observation; wait until that result is no longer reusable before confirming the change. Opening a stored report does not start another check.

You do not need to upload a private key or share hosting credentials to inspect a publicly presented certificate.

Check the endpoint visitors actually reach

A certificate is presented during the TLS handshake, before an HTTP redirect is processed. Therefore, https://www.example.com needs a certificate covering www.example.com even when its only purpose is to redirect to https://example.com.²

The same distinction matters when a CDN or reverse proxy sits in front of an application. A public check observes the certificate at the public TLS endpoint; it does not automatically inspect the separate connection between that proxy and the origin server.

Hostname coverage: does the certificate cover this name?

The certificate's Subject Alternative Name extension, usually shortened to SAN, contains the names relevant to modern hostname verification. The subject name shown in a report is useful identification, but it is not a substitute for checking hostname coverage.³

Consider these examples:

Scroll the table horizontally to compare all columns on a small screen.

The Hostname and SAN details section can omit entries when the display limit is reached; the report says when this happens. Hostname verification uses the original certificate, including entries omitted from display.

A wildcard covers one label at the leftmost position. A certificate can include several SAN entries, so the complete set of entries determines its coverage.³

If hostname coverage fails, inspect the names in the certificate and the hostname in your report. Then check that the correct certificate is assigned to that virtual host, proxy or load balancer. Issuing a new certificate will not help if the server continues presenting a different one.

Validity dates: valid now, expired or not yet valid?

The Valid from and Valid until fields define the certificate's validity period. Remaining at check time expresses the time left at the recorded observation, rather than a continuously updating countdown.⁴

Three results need different responses:

• Expired: renew or replace the certificate, deploy it to the TLS endpoint and reload the relevant service if required.
• Not yet valid: inspect the certificate's start date and verify the clocks used by the affected systems.
• Valid but approaching expiry: check that automated renewal and deployment work before the remaining time becomes critical.

An advisory threshold, such as 14 days, is a warning boundary used by the checker. It is not the expiry date and does not shorten the certificate's validity.

Renewal and deployment are separate steps. A new certificate may exist on disk while a running proxy still serves the previous certificate. Compare a fresh report's expiry date and fingerprint with the certificate you intended to deploy.

How the certificate chain works

The website certificate is often called the leaf or end-entity certificate. Its issuer is usually an intermediate certificate authority. Intermediate certificates connect the leaf to a trust anchor recognized by the client.⁵

A simplified example is:

Website certificate → intermediate CA → trusted root

Real deployments may involve more intermediates or alternative paths. The server normally provides the leaf and the intermediates needed by clients. The root does not normally need to be sent: trust must come from the client's trust configuration, not simply from receiving another certificate.⁵⁶

Presented chain and verified trust path are different

PeerPeek's Presented chain lists the certificates obtained from the server. It records what the endpoint supplied; it is not, by itself, evidence that those certificates form a trusted path.

The Trust path at check time result describes verification using the recorded CA store and profile. Hostname coverage is evaluated separately; a passed trust result does not establish a hostname match. The verifier can use trusted certificates from that store when building its path. Consequently, the displayed server chain and the path used for verification need not be identical.⁶

A truncated presented chain limits trust verification; the report marks that result Unknown. The checker does not fetch missing issuers from certificate-embedded URLs.

A longer presented chain is not automatically better. Inspect the certificates and the verification result instead of judging the configuration by certificate count.

Why a missing intermediate causes problems

A server may present a valid leaf certificate without the intermediate needed to connect it to a trusted issuer. Some clients may already possess the missing intermediate while others do not, making the same configuration appear to work inconsistently.⁷⁸

For a public website, the practical fix is to install the appropriate server certificate chain supplied by the CA. Do not ask visitors to bypass browser verification.

Common certificate problems and where to look

The situations below are diagnostic explanations, not promises that PeerPeek displays these exact error labels.

A trust failure alone does not establish that a certificate was forged. Private PKI certificates, for example, can be intended for clients configured with a private trust anchor. Such a certificate is unsuitable for unrestricted public access unless the intended visitors already trust that authority.⁶

Issuer, fingerprint and other certificate details

These fields help identify what the server presented. Most do not need an independent “good” or “bad” label.

A fingerprint is not a private key and cannot be used to decrypt traffic. When the fingerprint changes, investigate whether a renewal, reissue or another certificate deployment explains it. A changed fingerprint is not automatically a security incident.⁴

Why two checkers can return different trust results

Trust depends on the verification environment as well as the certificate. PeerPeek records Engine and trust provenance to make that environment identifiable.

The engine, php and openssl fields identify software involved in producing the report. The ca_sha256 value identifies the CA-store artifact used by the check. The trust_profile identifies the verification configuration, and capture_mode identifies the acquisition method. Missing provenance values are shown as unavailable; they do not establish a verification environment. These values make reports easier to compare; they are not grades for the website.

Platforms can differ in their trusted authorities and path-building behavior. A positive result therefore describes PeerPeek's recorded environment, rather than guaranteeing identical behavior in every browser or older device.⁷

If results disagree, first compare the hostname, check time and leaf fingerprint. Different certificates or observations made before and after a deployment are different inputs. If those match, investigate the presented intermediates and the clients' trust configurations.

What a passing report does not establish

PeerPeek SSL Checker does not currently check certificate revocation. A certificate can be revoked before its expiry date, for example after private-key compromise. Certificate Revocation Lists and other supported revocation mechanisms address a different question from ordinary date and chain checks.⁹¹⁰

The report also should not be treated as a complete audit of TLS protocol versions, supported cipher suites, application vulnerabilities or the origin behind a CDN. A valid certificate does not establish that the page is free of phishing or malicious content.

A stored report is a snapshot. Its public retention deadline concerns report availability, not certificate validity, and it does not mean the endpoint is monitored continuously.

Example: fixing a certificate mismatch on www

Suppose example.com passes, but www.example.com fails hostname coverage. The certificate lists only example.com.

Adding a DNS record for www makes that name resolve. It does not add www to the certificate. Configuring an HTTPS redirect also does not remove the need for hostname coverage on the initial connection.

The remedy is to obtain a certificate covering both names, configure the www HTTPS endpoint to use it, and set the desired redirect. Afterwards, check both hostnames again. This separates three jobs that are easily confused: DNS resolution, TLS verification and HTTP redirection.²

Check again after the fix

Submit the affected hostname in PeerPeek SSL Checker again. Confirm that the check time is after your fix; a reused cached result cannot verify a later change. Confirm coverage, validity and trust separately, then inspect the fingerprint and dates to establish that the expected certificate is being served.

Open SSL Checker to verify your certificate.

Compare the earlier report while it remains available. Public reports are retained for up to 24 hours; keep any details you need before the displayed retention deadline. An earlier report describes the earlier observation, not a live status page.