raatools/

SSL Certificate Checker

Check SSL/TLS certificate details for any domain.

What is an SSL certificate checker?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) encrypt the connection between a web browser and a server, protecting data in transit from eavesdropping and tampering. An SSL certificate proves that a website is who it claims to be. This tool checks whether a domain's SSL certificate is valid, properly configured, and not expired.

When you visit a website with HTTPS, your browser verifies the SSL certificate before establishing the encrypted connection. If the certificate is expired, issued for a different domain, or signed by an untrusted authority, the browser displays a security warning. This tool performs the same checks and provides detailed information about the certificate.

Why HTTPS and TLS matter

TLS (Transport Layer Security) provides three critical guarantees for every HTTPS connection. First, encryption: all data exchanged between the browser and server is encrypted so that anyone intercepting the traffic — on a coffee-shop Wi-Fi network, for example — sees only scrambled bytes. Second, integrity: TLS uses message authentication codes (MACs) to detect tampering in transit, ensuring that neither the request nor the response has been modified. Third, authentication: the certificate lets the browser verify it is talking to the real server and not an impersonator performing a man-in-the-middle attack.

Beyond security, HTTPS has become a ranking signal for Google Search and a prerequisite for modern browser features such as Service Workers, geolocation, and camera access. Browsers like Chrome and Firefox mark HTTP pages as 'Not Secure', which erodes user trust and increases bounce rates. Sites without a valid certificate can also appear on threat-intelligence block lists used by corporate firewalls, cutting off entire audiences.

What the checker reports in detail

A full SSL/TLS certificate check goes beyond a simple pass/fail. Here is what each field tells you:

  • Validity dates and expiry — The certificate contains a notBefore and notAfter timestamp. The checker confirms the current date falls within that window and shows how many days remain before expiry. Any value under 30 days should trigger an immediate renewal.
  • Issuer and Certificate Authority (CA) — The issuer field identifies the CA that signed the certificate: for example, 'Let's Encrypt Authority X3', 'DigiCert TLS RSA SHA256 2020 CA1', or 'Sectigo RSA Domain Validation CA'. Recognising the issuer helps you verify that a site uses a trusted CA and not an obscure or private one.
  • Subject and Subject Alternative Names (SANs) — The subject CN (Common Name) was historically the hostname the certificate was issued for. Modern certificates rely on SANs, a list of every domain and subdomain the certificate protects. A single certificate can cover both example.com and www.example.com, or dozens of subdomains. A mismatch between the hostname you connect to and the SAN list triggers a name-mismatch error.
  • Chain of trust — Browsers trust a small set of root CAs pre-installed in the operating system. Your server certificate is almost never signed directly by a root; instead it is signed by an intermediate CA, which is itself signed by the root. The server must send the full chain — leaf certificate plus all intermediate certificates — so browsers can build the trust path. A missing intermediate is one of the most common causes of certificate errors on mobile devices.
  • Key type and signature algorithm — The checker shows the public key algorithm (RSA 2048-bit or RSA 4096-bit being most common; ECDSA P-256 is increasingly popular for performance) and the signature algorithm used by the CA (SHA-256 with RSA, for example). SHA-1 signatures have been deprecated since 2017 and will cause browser errors; SHA-256 is the current standard.

What this tool checks

  • Certificate validity — whether the certificate is currently valid and not expired.
  • Domain match — whether the certificate covers the domain you entered.
  • Certificate chain — whether the chain of trust from the certificate to a root CA is complete.
  • Expiration date — how many days until the certificate expires.
  • Issuer information — which Certificate Authority issued the certificate.

How to use this tool

Enter a domain name (like example.com) and the tool connects to the server, retrieves the SSL certificate, and displays its details. You will see the subject, issuer, validity dates, certificate type (DV, OV, EV), and any configuration issues. Use this to monitor your own certificates or verify that a website you plan to share data with is properly secured.

Certificate types

Domain Validation (DV) certificates only verify domain ownership and are the most common (used by Let's Encrypt). Organization Validation (OV) certificates verify the organization behind the domain. Extended Validation (EV) certificates require the most thorough verification. All three provide the same level of encryption — the difference is in the identity verification of the certificate holder.

Common certificate errors and what they mean

Browser and server TLS stacks are strict. The following errors are the most frequently encountered:

  • Certificate expired (NET::ERR_CERT_DATE_INVALID) — The current date is past the notAfter timestamp. The connection is blocked by default in all major browsers. Fix: renew the certificate immediately. If you use Let's Encrypt, run certbot renew or check why your automated renewal cron job or systemd timer failed.
  • Hostname mismatch (NET::ERR_CERT_COMMON_NAME_INVALID) — The domain in the address bar does not appear in the certificate's SAN list. Common causes: the certificate was issued for www.example.com but the site is also served from example.com (without www), or an old certificate was left on a server after a domain change. Fix: reissue the certificate to include all required hostnames.
  • Self-signed certificate — The certificate was signed by the same key it protects, rather than by a trusted CA. Browsers have no way to verify the identity, so they display an 'untrusted certificate' warning. Self-signed certificates are acceptable on internal networks and development environments, but must never be used on public-facing production sites.
  • Untrusted root — The certificate was issued by a CA that is not in the browser's or operating system's trust store. This can happen with private CAs, some national CAs that have been removed from trust stores, or when using a newly established CA whose root certificate has not yet been widely distributed. Fix: switch to a well-known public CA.
  • Incomplete certificate chain — The server is sending only the leaf certificate without the required intermediate CA certificates. The browser cannot build the trust path to a root CA. Desktop browsers sometimes recover by fetching the missing intermediate via AIA (Authority Information Access), but mobile browsers and many API clients do not. Fix: configure your web server (nginx, Apache, Caddy) to serve the full chain bundle.

Certificate renewal and automation

Let's Encrypt, the free, automated, and open CA run by the Internet Security Research Group (ISRG), has transformed certificate management. Let's Encrypt certificates have a 90-day validity period by design — the short lifespan limits the damage from a compromised private key and encourages automation. The ACME protocol (Automated Certificate Management Environment, RFC 8555) lets a client like Certbot, acme.sh, or a cloud load balancer automatically prove domain control (via HTTP-01 or DNS-01 challenges) and retrieve a fresh certificate without human interaction. When configured correctly, ACME clients renew certificates around 30 days before expiry, making manual renewal unnecessary.

Even with automation, monitoring is essential. Automation can silently fail due to firewall changes, DNS misconfiguration, rate-limit exhaustion, or a lapsed service account. Best practice is to set up an external expiry monitor — a cron job, a third-party service, or an uptime tool — that alerts you when a certificate's remaining validity drops below 21 days. Catching a failed renewal while you still have three weeks of buffer is far less stressful than discovering an expired certificate from your users.

Common mistakes to avoid

  • Relying on calendar reminders instead of automation — Human-managed renewals fail when the responsible engineer is on holiday or changes job. Use an ACME client with a systemd timer or cron job and verify the job is actually running.
  • Deploying an incomplete certificate chain — Copying only the leaf certificate to the server and omitting intermediate certificates causes errors on mobile devices and non-browser clients even though desktop Chrome may appear fine (it silently fetches the missing intermediate).
  • Forgetting subdomains — Issuing a certificate for example.com but not www.example.com, or vice versa, produces hostname-mismatch errors. Use a wildcard certificate (*.example.com) or a SAN certificate listing all required hostnames.
  • Ignoring expiry warnings — Many ACME clients email a warning when a certificate is near expiry and the automated renewal has not run. These emails are easy to miss in a noisy inbox. Set up a dedicated alert channel (Slack, PagerDuty, or similar) for certificate expiry notifications.

Frequently asked questions

What happens when an SSL certificate expires?

Browsers display a prominent security warning that discourages visitors from proceeding. Most users will leave rather than bypass the warning, causing significant traffic loss. Search engines may also demote the site in rankings. Modern tools like Let's Encrypt and Certbot automate renewal to prevent accidental expiration.

Is SSL the same as TLS?

SSL is the older protocol (last version: SSL 3.0 from 1996). TLS is the modern successor (current: TLS 1.3). All SSL versions are now considered insecure and deprecated. When people say SSL today, they usually mean TLS. Certificates are still commonly called SSL certificates even though they use TLS for the actual encryption.

What is a certificate chain and why does it matter?

A certificate chain (or trust chain) is the sequence of certificates from your server's leaf certificate up to a trusted root CA. Browsers trust only a small number of root CAs, but those roots sign intermediate CAs, which in turn sign server certificates. Your web server must send the leaf plus all intermediate certificates in the TLS handshake. If an intermediate is missing, clients that have not cached it will fail to verify the certificate and display an error — even though the certificate itself is perfectly valid.

How long are SSL/TLS certificates valid?

Browser-trusted public certificates have a maximum validity of 398 days (about 13 months) as mandated by the CA/Browser Forum since September 2020. Let's Encrypt issues certificates valid for 90 days to encourage automation. Internal or private CA certificates can have longer validity periods, but best practice is to keep them under two years. Shorter-lived certificates reduce the window of exposure if a private key is ever compromised.