A TLS certificate is a digital file that a website presents to your browser when you connect over HTTPS. Its job is simple: it proves the domain you reached really is the domain it claims to be, and it provides the public key used to encrypt the connection. Without a valid certificate, HTTPS cannot be trusted, and everything you send could be readable or modifiable by someone in between.
When you see the padlock in your browser address bar, it means a certificate was presented and accepted. What the padlock does not tell you is whether the certificate is fresh, correctly configured, or issued by a trustworthy authority. That is what certificate inspection is for.
Every certificate carries a fixed set of readable fields. The important ones are:
Subject and Subject Alternative Names (SAN): the exact domain names the certificate is valid for. A mismatch here, for example visiting www.example.com on a certificate issued only for example.com, produces a browser warning.
Issuer: the Certificate Authority (CA) that signed it. Your device only trusts certificates chaining back to a CA in its trusted root store.
Validity period: a not-before and not-after date. An expired certificate is one of the most common causes of HTTPS errors, and one of the clearest signs of a neglected server.
Public key and signature algorithm: what key type and strength the site uses. RSA 2048 and ECDSA P-256 are common and sound; SHA-1 signatures or 1024-bit RSA are outdated and a red flag.
Serial number and fingerprints: unique identifiers used for revocation checks and pinning.
A certificate does not stand alone. The server also presents the intermediate certificates that link its own certificate back to a root CA. If the chain is incomplete, some browsers will accept the site while others fail, which is a classic misconfiguration. A full inspection shows the entire chain and whether any link in it is weak or expired.
The SSL Certificate Inspector in the toolkit retrieves a live certificate from any public domain and breaks it down for you:
Enter a domain name and run the tool. It reports the subject and SAN entries, the issuer, the validity window with days remaining, the key algorithm, and the fingerprints. Use it to check a site before trusting it with a login, to verify a certificate renewal took effect, or to see whether a server is presenting the correct chain.
Things worth looking at in the results:
Days remaining near zero mean an outage is imminent. A subject that does not match the domain you typed means the connection is not proving what it should. An issuer you do not recognise is worth investigating before entering credentials anywhere on that site.
Certificates are a first line of defence. Attackers who can present a trusted certificate for a domain they do not own, for example through a compromised CA or a phishing domain with a lookalike name, get a padlock that reassures victims. Reading the actual certificate details instead of trusting the padlock is a habit that protects you. If you run your own site, monitoring expiry dates and key strength is basic hygiene that prevents both outages and downgrade attacks.
The following tools are commonly associated with this topic for research, testing, and defense:
Live certificate lookup for any public domain, available in the EDX toolkit.
Check remaining validity days before outages happen on sites you manage.
See the Certificate Transparency guide for discovering subdomains through public certificate logs.
This guide is for educational purposes only. Only inspect certificates for domains you own or have permission to assess. Do not use this knowledge for malicious activities. Always follow the law and ethical guidelines.