SSL Certificate Checker

What this check actually does

It completes a TLS handshake with your host on port 443 — the same handshake a browser performs — and then reads the certificate the server presented before closing the connection. No page is requested and no data is exchanged beyond the handshake itself. What comes back is the certificate as the public internet receives it.

That distinction matters more than it sounds. Your own browser has been to your site before: it may have cached an intermediate certificate your server forgot to send, it may hold a manual exception you added months ago, and on a corporate network it may be trusting an inspection proxy's certificate rather than yours. A check from outside has none of that history, which is why it finds problems your browser quietly papers over.

The certificate chain

A certificate on its own proves nothing. Trust comes from a chain: your certificate is signed by an intermediate, the intermediate is signed by a root, and the root is already present in the client's trust store because its operator passed an audit. Verification walks that chain upward, and it succeeds only if it arrives at a root the client already trusts.

The practical consequence is one sentence long: your server must send the intermediate, and must not bother sending the root. A chain length of 1 in the result above almost always means the intermediate is missing, which is the single most common real-world TLS misconfiguration. It presents as “works in my browser, fails for some visitors”, because whether it works depends entirely on whether that particular client happens to have seen the intermediate before.

What expiry really means

A certificate carries two timestamps, notBefore and notAfter, and clients enforce both against their own clock. There is no grace period. One minute past notAfter the certificate is as invalid as it will ever be, and browsers replace your site with a full-page interstitial that most visitors will not click through. Anything that is not a browser — a mobile app, a payment integration, a webhook — typically refuses outright, with no override available to anyone.

Two failure modes cause most expiry outages, and neither is forgetting the date:

• Renewed but not reloaded. The new certificate is on disk and the old one is still in memory. Nginx, Apache and HAProxy all serve what they loaded at startup, so a renewal without a reload changes nothing at all — and this check will still show the old expiry date, which makes it a reliable way to confirm the reload worked.
• Renewed on one host only. Behind a load balancer or across several web servers, it is entirely possible for one node to serve a fresh certificate and another to serve an expired one. Visitors then see an intermittent failure that reproduces for nobody reliably.

Automate renewal and monitor the result rather than the calendar. An ACME client renews at roughly 30 days remaining, which leaves a wide margin for a failed renewal to be noticed and fixed.

Why a self-signed certificate fails

A self-signed certificate is one that signs itself: it is its own issuer, and it vouches for nothing beyond its own existence. The encryption it provides is genuine and exactly as strong as any other certificate's — this is the part people are usually surprised by. What it cannot provide is identity.

TLS solves two problems at once, and they are separable. Encryption stops a network observer reading the traffic. Authentication establishes that the party at the other end is really the domain you asked for. Without the second, the first is close to worthless: an attacker who intercepts the connection can present their own self-signed certificate and encrypt the traffic perfectly well — to themselves. A browser cannot distinguish that attack from a legitimate self-signed certificate, because at the protocol level they are identical, which is why it refuses both.

Self-signed certificates are fine on a development machine or inside a network with its own internal CA distributed to every client. For anything a member of the public reaches, use a publicly trusted certificate — they are free and automatable, so the historical excuse for not doing so is gone.

SAN versus common name

The common name (CN) is a single field inside the subject, and it is a historical accident. It was never designed to carry a host name; it was borrowed for that purpose in the early days of the web and everyone regretted it, because one field cannot describe a certificate that covers several names.

The subject alternative name extension (SAN) replaced it. It is a list, it can carry DNS names, IP addresses and other identifier types, and it is what every current client checks. Chrome stopped consulting the common name entirely in 2017 and the other major browsers followed, so today the rule is simply:

• The name a visitor typed must appear in the SAN list, or the connection is rejected.
• A matching common name does not help if the SAN list does not also contain the name. The CN is displayed for information and nothing more.
• example.com and www.example.com are different names. Both must be listed; a certificate for one does not cover the other. This is the most common cause of a host-name mismatch.
• A wildcard such as *.example.com matches exactly one label — a.example.com yes, a.b.example.com no, and the bare example.com no.

How IPGet keeps this safe

A feature that makes a server open a connection to an address a stranger supplied is a server-side request forgery primitive. The certificate checker uses the same destination guard as the Port Checker, and does all of the following on every request:

• Accepts a host name, or an http/https URL reduced to its host. Any other scheme is refused, and a URL carrying a username and password is refused rather than stripped.
• Resolves the name itself and checks every returned address. If any one of them is private, loopback, link-local, carrier-NAT, multicast or reserved, the whole request is refused — not just that address — so a zone mixing a public and a private record cannot be used to reach the private one.
• Connects to the resolved address, never to the host name. The name travels only as the TLS server name, so the certificate you get is the right one, while the socket goes to an address we already validated. Handing the name to the socket would resolve it a second time, and whoever controls that zone could answer with a public address for the check and 127.0.0.1 a moment later. That is DNS rebinding.
• Connects to port 443 only, as a fixed constant. The port can never come from the request.
• Reads the certificate and closes. Nothing is written to the socket, no page is fetched, and the connection is destroyed on every path — success, failure and timeout alike.
• Reports only descriptive fields: subject, issuer, dates, names, fingerprints. The public key and the raw certificate bytes are never returned.
• Applies a short timeout, per-address rate limits, and a brief cache of successful results. Checked domains are not logged or stored; see the privacy policy.

Verification is deliberately not enforced on our side — that is what allows the tool to describe an expired or self-signed certificate instead of refusing to speak to it. The verification result is not discarded, though: the chain check and host-name check both still run, and their outcome is exactly what the badge above reports.