SSL/TLS Certificate Inspector

What a TLS certificate proves

When you connect to an HTTPS site, the server presents a certificate signed by a trusted Certificate Authority (CA). The certificate binds a public key to a hostname, and the signature proves the CA verified that binding. Your browser checks the signature chain back to a root CA it trusts, and only then does it complete the TLS handshake.

Things to check on any certificate

• Expiration date — modern certs are 90 days (Let's Encrypt) or 1 year (commercial). If a cert is close to expiry on a production site, that's a renewal issue brewing.
• Subject (CN) and SANs — what hostnames this cert is valid for. The browser will warn if the hostname you're visiting isn't on the list.
• Issuer — which CA signed it. Let's Encrypt, DigiCert, Cloudflare, Sectigo, Google Trust Services are all common.
• Key algorithm and size — RSA-2048 is the floor; ECDSA P-256 is preferred (smaller, faster). RSA-4096 is fine but overkill for most uses.
• Signature algorithm — must be SHA-256 or better. SHA-1 was deprecated in 2017.
• Full chain — does the server send the intermediate certs? Missing chain breaks some clients (Java, older Android).

How TLS errors usually look

• NET::ERR_CERT_DATE_INVALID — the cert is expired (or system clock is wrong).
• NET::ERR_CERT_AUTHORITY_INVALID — self-signed cert, or chain doesn't lead to a trusted root.
• NET::ERR_CERT_COMMON_NAME_INVALID — the cert is for a different hostname.
• SSL_ERROR_BAD_CERT_DOMAIN — same as above (Firefox).

What a TLS certificate actually proves

A TLS certificate is a signed statement from a Certificate Authority saying "the entity that controls this public key also controls this domain name." When your browser connects to https://example.com, the server presents its certificate, the browser verifies the CA signature and the domain match, then uses the certificate's public key to establish an encrypted session. If any step fails, the browser shows a security warning.

Because certificates gate access to modern web infrastructure, inspecting them is a routine part of network administration. What CA issued it. When it expires. What names it covers. What algorithm signed it. All of these matter for different reasons.

The fields I check when I inspect a certificate

Subject Alternative Names (SANs)

The single most important field on a modern certificate. SANs list every hostname the certificate is valid for. A cert issued for example.com might include example.com, www.example.com, api.example.com, and *.example.com as SANs. The browser checks the site you're visiting against these names — if you're at admin.example.com but the certificate only has SANs for www.example.com and api.example.com, the browser rejects it.

The old Common Name (CN) field was originally used for this purpose but has been deprecated in favor of SANs since 2019. Modern browsers ignore the CN entirely and check only SANs. If you see a certificate with a CN but no matching SAN, it will fail validation in Chrome, Firefox, Safari, and Edge.

Issuer

Which Certificate Authority signed this certificate. Common issuers include Let's Encrypt (free, automated), Google Trust Services (free, automated, mostly for Google Cloud), DigiCert (commercial, longstanding), Sectigo (formerly Comodo, high volume), and Amazon (specific to AWS services). The issuer identity tells you something about how the certificate was obtained — Let's Encrypt certs are automatic; DigiCert commercial certs go through more identity verification.

An unfamiliar issuer name is worth investigating. Legitimate but obscure CAs exist; so do fraudulent certificates issued by compromised CAs or by CAs that shouldn't be trusted. The browser's built-in trust store contains a specific list of trusted CAs; certificates issued by CAs outside that list produce browser warnings.

Validity period (not-before and not-after)

When the certificate is valid from and until. Modern certificates issued to the public web max out at 90 days for Let's Encrypt and 398 days (about 13 months) for commercial CAs. Google announced plans to further reduce the maximum to 90 days for all publicly-trusted certificates in the coming years.

Expired certificates cause outages. Even by a few hours. If a business's website suddenly shows a security warning, "did the cert expire" is one of the first questions to check. Automated renewal (via ACME clients like certbot, cert-manager, or the built-in renewal in web servers) has largely eliminated this class of problem, but it still happens.

Key size and algorithm

Modern certificates use either RSA (typically 2048 or 3072-bit keys) or ECDSA (typically P-256 curve). ECDSA certificates are smaller and faster than RSA. Some servers need RSA for compatibility with older clients, but this compatibility gap has largely closed and ECDSA is now the default for new deployments.

Certificate signature algorithms are SHA-256 across essentially all modern certs. Older SHA-1 signatures are no longer trusted by any major browser. If you see a SHA-1 signature on a currently-in-use certificate, that's a serious finding — the cert is likely broken already or will be soon.

Chain of trust

A certificate is signed by an intermediate CA, which is itself signed by a root CA. The chain has to be complete and trusted for the certificate to validate. Missing intermediate certificates in the server's configuration is a common misconfiguration — the site works in browsers with cached intermediates but fails for clients that don't have them.

Common problems I see

Missing intermediate certificates

The server sends its own leaf certificate but not the intermediate CA cert. Browsers that have already cached the intermediate work fine; new clients don't have it and fail validation. Fix: configure the server to send the full chain (leaf + intermediates, not the root — the root is already in client trust stores).

Hostname mismatch

The certificate's SANs don't include the hostname the client is trying to reach. Might be a config error (wrong cert deployed), might be a legitimate need for a wildcard or a multi-domain cert that wasn't provisioned. Fix: get a certificate covering the actual hostnames in use.

Expired certificate

The not-after date has passed. Renewal automation failed, or was never set up. Fix: renew immediately, and set up automation so this doesn't happen again.

Not yet valid

The not-before date is in the future. Usually means clock skew — either the server or the client has a wrong time. Fix: sync clocks with NTP.

Self-signed certificate

The certificate is signed by itself rather than by a trusted CA. Legitimate for internal development or specific closed systems; not acceptable for public web services. Browsers reject with a security warning.

Weak signature algorithm or small key

SHA-1 signatures, RSA keys under 2048 bits. Rejected by modern browsers. Fix: reissue with modern parameters.

Wrong certificate deployed

The web server is presenting a certificate for a completely different domain than the one the client is requesting. Usually a mistake in configuring virtual hosts or SNI. Fix: match the certificate to the site it's supposed to serve.

Wildcards, multi-domain, and EV

Wildcard certificates

A wildcard cert covers any single-level subdomain of a domain. A cert for *.example.com is valid for www.example.com, api.example.com, mail.example.com, and any other single-level subdomain. It does not cover multi-level subdomains — dev.api.example.com would need its own SAN or its own wildcard cert (*.api.example.com).

Wildcards are convenient but come with a security tradeoff: if the private key is compromised, every subdomain is affected. Some organizations prefer separate certs per subdomain to limit blast radius.

Multi-domain (SAN) certificates

A cert can list many different domains in its SANs, not just subdomains of one domain. A cert with SANs for example.com, example.net, and example.org is valid for all three. Common in commercial certs where a company owns multiple related domains.

Extended Validation (EV) certificates

An older category of certificate where the CA performs additional identity verification on the requester before issuing. Browsers used to display the organization name prominently for EV certs (a green bar with the company name). Modern browsers have largely stopped displaying EV indicators, so the practical value of EV certs has diminished. Still used by some banks and other high-trust sites.

Automated certificate management

The ACME protocol (Automated Certificate Management Environment), used by Let's Encrypt and increasingly by other CAs, lets a client automatically prove control of a domain and obtain a certificate without any human involvement. This eliminates the "renew every year" manual work that used to be a major source of certificate outages.

Certbot is the reference ACME client. Web servers like Caddy, Traefik, and modern NGINX have built-in ACME support. Container orchestration platforms like Kubernetes have cert-manager. Every modern deployment should be using automated certificate management. Manually running openssl commands and renewing certs by hand every year is a legacy practice that produces outages when someone forgets.

What Certificate Transparency reveals

Since 2018, publicly-trusted certificates are logged to Certificate Transparency logs, which are public and searchable. Anyone can look up every certificate ever issued for a domain. Services like crt.sh let you search these logs.

This has security implications. If someone registers a fraudulent look-alike domain and gets a certificate for it, that certificate is now in the public logs and can be detected by domain owners monitoring for their name. Companies that care about brand protection subscribe to CT log monitoring services that alert them to new certificates issued for their trademarks or lookalikes.

It's also useful defensively. If you're investigating a suspicious domain, checking its CT log history tells you when certificates were first issued (often coincides with when the domain became active), what CA the operator uses, and whether they've operated other similar domains.

Related tools

If you're auditing a site more broadly, the HTTP Headers Inspector shows security-relevant headers like HSTS and CSP that pair with proper TLS. The Domain Infrastructure Lookup shows the DNS records and hosting providers for a domain, useful for confirming the site is where it claims to be.

For email TLS specifically, the Email Header Analyzer shows the TLS status of each SMTP hop, which is often more revealing than looking at the mail server's certificate directly.

Privacy

The certificate inspector makes a TLS handshake to the target host from our Cloudflare Worker and reads the presented certificate. The target site sees the connection from Cloudflare's IP range, not from your IP. The tool doesn't visit any other resources on the site — no page rendering, no cookies, no javascript execution. Just the TLS handshake and cert extraction.