SSL Certificate Check: Verify Any Website's Security in Seconds

An SSL certificate check tells you whether a website's HTTPS connection is properly configured: valid certificate, complete chain, correct hostname, strong protocol, and reasonable expiry window. That sounds like a long list, but every item maps to a specific failure mode that browsers, API clients, or mobile apps will punish with a trust warning or a hard connection refusal. The check itself takes seconds. Understanding the results and knowing which failures are urgent is where the real value sits.

This guide walks through what an SSL check actually examines, how to run one from a browser or the command line, what the different certificate types mean in practice, and why a single point-in-time check is never enough on its own. If you want a quick result before reading further, run your domain through the SSL Certificate Checker and come back with the output open.

What an SSL Certificate Check Examines

A thorough SSL certificate check is not just a green-or-red pass/fail. It evaluates several independent properties, and a site can pass on most while failing on one that still breaks the connection for certain clients. Each property below maps to a distinct class of incident, which is why tools that only check expiry dates miss most of the interesting problems.

• Validity dates. The certificate's Not Before and Not After timestamps define the window during which clients will accept it. Expired certificates are the single most common SSL failure in production.
• Hostname match. The Common Name (CN) and Subject Alternative Names (SANs) must include the exact hostname the client is connecting to. A certificate for example.com will not automatically cover www.example.com unless both appear in the SAN list.
• Chain completeness. Browsers need a path from the leaf certificate through one or more intermediates to a trusted root. Missing intermediates are the second most common cause of SSL warnings, and they often affect only some clients.
• Protocol version. TLS 1.2 and TLS 1.3 are the only versions considered safe. TLS 1.0 and 1.1 are deprecated and actively rejected by modern browsers. A check should confirm the server is not offering legacy protocols.
• Cipher suites. Even on TLS 1.2, weak ciphers like RC4, 3DES, or export-grade suites create real vulnerabilities. A good check flags which ciphers the server prefers and whether forward secrecy is negotiated.
• OCSP stapling. When configured, the server includes a signed revocation status response from the CA, saving the client from making a separate OCSP request. Absence is not fatal, but presence improves both performance and privacy.
• Certificate type. DV, OV, and EV certificates represent different validation levels. The type does not affect encryption strength, but it does indicate how thoroughly the CA verified the certificate requester's identity.

The SSL Grade tool evaluates all of these properties together and produces a letter grade, which is useful for comparing domains or tracking improvements over time.

How to Check with Browser Developer Tools

Every major browser lets you inspect a site's certificate without installing anything. The process is slightly different in each browser, but the information available is essentially the same: certificate subject, issuer, validity period, SANs, key type, and chain path.

• Click the lock (or tune) icon in the address bar. In Chrome and Edge, this opens a panel showing "Connection is secure" or a warning. Click through to "Certificate" to see details.
• Certificate tab: General. Shows the subject (who the certificate was issued to), issuer (which CA signed it), and the Not Before / Not After validity dates. This is the fastest way to check if a certificate is current.
• Certificate tab: Details. Shows the full Subject Alternative Name list, the public key algorithm and size (RSA 2048, ECDSA P-256, etc.), the signature algorithm, serial number, and any extensions like OCSP URLs.
• Certificate tab: Certification Path. Displays the chain from leaf to root. If the chain is incomplete or if the root is not in the browser's trust store, the path will show a warning icon on the broken link.
• Security tab in DevTools. In Chrome, open DevTools (F12), navigate to the Security tab. This shows the protocol version (TLS 1.2 or 1.3), the cipher suite negotiated, and whether the certificate is valid for the current origin.

Browser checks are convenient but limited. They show what your specific browser negotiated, not what the server supports. A server might still offer TLS 1.0 to older clients even though your browser connected on TLS 1.3. For a complete picture of supported protocols and ciphers, you need a server-side scan.

Command-Line SSL Checks

The openssl command-line tool is the standard way to inspect SSL/TLS connections outside a browser. It ships with most Linux distributions and macOS, and it gives you raw access to the handshake, certificate chain, and negotiated parameters. Two commands handle the majority of practical checks.

# Connect and display the full certificate chain
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -text

# Key fields to look for in the output:
#   Issuer:          Who signed the certificate (CA name)
#   Subject:         The entity the certificate identifies
#   Not Before:      Start of validity window
#   Not After:       End of validity window (expiry)
#   Subject Alternative Name:  All hostnames covered
#   Public Key Algorithm:      RSA, ECDSA, Ed25519
#   Signature Algorithm:       sha256WithRSAEncryption, etc.

The -servername flag sends the SNI (Server Name Indication) extension, which is essential when a server hosts multiple domains on the same IP. Without it, you may receive the default certificate instead of the one that matches your target domain. This is a common source of confusion when checking shared hosting or CDN-fronted sites.

# Quick check: shows protocol, cipher, certificate dates, and chain
curl -vI https://example.com 2>&1 | grep -E '(SSL|subject|issuer|expire|TLS)'

# Example output lines:
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
# * subject: CN=example.com
# * issuer: C=US; O=Let's Encrypt; CN=R11
# * expire date: Sep 15 12:00:00 2026 GMT

The curl approach is faster for a spot check when you just need to confirm the protocol version, issuer, and expiry. For deeper analysis, including the full chain, supported cipher list, and protocol negotiation details, the openssl command gives complete control.

# Print just the expiry date (useful in scripts and cron jobs)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -enddate

# Output: notAfter=Sep 15 12:00:00 2026 GMT

Understanding Certificate Types

Certificate Authorities issue three types of certificates, distinguished not by encryption strength but by how rigorously they verify the requester's identity before signing. The encryption is identical across all three types. What changes is the level of assurance about who controls the domain and organization behind it.

• DV (Domain Validated). The CA confirms that the requester controls the domain, usually through a DNS record, HTTP file, or email challenge. Let's Encrypt issues DV certificates, and automated issuance takes minutes. DV is appropriate for the vast majority of websites.
• OV (Organization Validated). The CA also verifies the legal organization behind the domain by checking business registration documents. The certificate's Subject field includes the organization name. OV adds identity assurance but no visible browser difference from DV.
• EV (Extended Validation). The CA verifies the legal entity, physical address, and operational existence. Browsers once showed a green bar for EV, but Chrome, Firefox, and Safari removed that indicator by 2020. The validation is real; the visual signal is gone.

In 2026, the practical difference between types comes down to trust signals outside the browser chrome. EV certificates still carry the verified organization name in the certificate subject, which matters for compliance frameworks, partner due diligence, and automated systems that inspect certificate metadata. For most sites, DV with proper automation and monitoring provides the security users actually need. The real risk is not the certificate type; it is letting any certificate expire, misconfiguring the chain, or failing to detect unauthorized issuance.

Common SSL Check Failures

When an SSL certificate check fails, the failure usually falls into one of six categories. Each has a different severity, a different root cause, and a different fix. Knowing which category you are dealing with saves time and prevents the wrong remediation.

• Expired certificate. The most frequent failure. Automated renewal with Let's Encrypt or ACME-compatible CAs eliminates most cases, but renewal can still fail silently if DNS validation breaks or if the renewal process loses access to the hosting account.
• Hostname mismatch. The domain in the browser does not appear in the certificate's CN or SAN list. Common after domain migrations, subdomain additions, or when a CDN serves a certificate that does not cover all configured origins.
• Incomplete chain. The server sends the leaf certificate but omits one or more intermediates. Modern browsers may handle this through cached intermediates, but API clients, mobile apps, and older systems will reject the connection outright.
• Weak or deprecated protocol. The server offers TLS 1.0 or 1.1, which are disabled in current browsers. Legacy system dependencies are the usual reason this persists. The fix is to disable old protocols and verify that all clients can negotiate TLS 1.2 or later.
• Self-signed certificate. Acceptable in development and internal tooling, but a hard failure in any browser or client that checks against the public root store. The fix is to replace with a CA-signed certificate, not to instruct users to bypass the warning.
• Revoked certificate. The CA has explicitly invalidated the certificate, usually because the private key was compromised or the certificate was mis-issued. OCSP and CRL checks catch this, though not all clients enforce revocation checking by default.

Priority matters. An expired certificate or hostname mismatch is an immediate user-facing outage and should be treated as a P1 incident. An incomplete chain may only affect certain clients and can sometimes be masked by browser caching, making it harder to detect but still worth fixing urgently. Weak protocols and self-signed certificates are security risks that compound over time. Revoked certificates are rare but indicate a serious underlying problem that warrants investigation beyond just replacing the certificate.

Automated Certificate Monitoring

A one-time SSL certificate check tells you the current state. It does not tell you when that state will change, whether someone issued a certificate you did not expect, or whether your renewal pipeline is actually working. Automated monitoring bridges that gap by turning certificate health from a manual spot check into a continuous signal.

The three pillars of certificate monitoring each catch a different class of problem. Expiry monitoring is the baseline: alert when a certificate is within 30, 14, and 7 days of expiry, and escalate if renewal has not happened by the 7-day mark. Chain validation on every deployment catches the incomplete-chain problem before users encounter it, which is especially important when infrastructure changes like CDN migrations or load balancer swaps silently alter what gets served. CT (Certificate Transparency) log monitoring watches the public issuance record for your domains and alerts when a certificate appears that your team did not request, which is an early signal of domain compromise, CA mis-issuance, or shadow IT.

• Expiry alerts. Set thresholds at 30, 14, and 7 days. If you use Let's Encrypt with a 90-day cycle, renewal should happen around the 60-day mark. An alert at 30 days means the automated renewal has already failed once.
• Chain validation on deploy. Add a post-deployment step that connects to the live endpoint and verifies the full chain. Catch missing intermediates before they reach users.
• CT log monitoring. Use the Certificate Transparency API to watch for new certificates issued for your domains. Unexpected entries may indicate phishing infrastructure, account compromise, or an internal team spinning up services without coordination.
• Multi-endpoint checks. If your domain resolves through multiple edges, CDN nodes, or regional load balancers, verify that all of them serve the same certificate and chain. Partial deployments create intermittent failures that are difficult to reproduce.

The Domain Monitor combines SSL expiry tracking with DNS and availability checks in a single view, which reduces the number of separate monitoring tools a team needs to maintain. For teams that manage dozens or hundreds of domains, the compounding value of automated monitoring is substantial: it converts a class of incident that always feels urgent and avoidable into a managed, observable process.

Putting It Together

An SSL certificate check is not a single thing. It is a collection of verifications that together determine whether a connection is trustworthy, correctly deployed, and likely to remain healthy. The fastest path for a manual check is to start with the SSL Certificate Checker for certificate details and chain status, then review the SSL Grade for protocol and cipher analysis. For ongoing assurance, set up monitoring through Domain Monitor and watch CT logs through the Certificate Transparency API.

The pattern that causes the most real-world damage is not exotic. It is a certificate that renewed successfully three times, failed silently on the fourth because a DNS record changed, and expired on a Friday evening while the team assumed automation had it covered. Checking once is useful. Checking continuously is what actually prevents outages.

Independent references: Review the SSL Labs Server Test for deep TLS analysis and Let's Encrypt Certificates for details on how the most widely used free CA operates.