Free SSL Certificate Checker & TLS Scanner

Real-time TLS handshake validation: certificate chain integrity, expiry countdowns, SAN enumeration, and protocol-version auditing — processed at the edge, retained nowhere.

Free, no sign-upLive results, nothing stored
Check a list of domains (Bulk batch mode)
Drop a .txt or .csv list of domains here, or browse file
One domain per line (up to 50 domains). Runs batch audit in-browser.
Try Examples:

Operational Workflow — Free SSL Certificate Checker & TLS Scanner

4-Stage Diagnostic Execution
Stage 01

Enter the target hostname (e.g. stripe.com or api.yoursite.com) into the input field. Subdomains are evaluated independently against their own certificate — not the apex domain's cert.

Stage 02

Click 'CHECK SSL CERTIFICATE' to initiate a live TLS handshake from our edge node. The scan completes in under two seconds.

Stage 03

Review the Certificate Authority issuer, the full SAN list, and the precise expiry date. Confirm the negotiated TLS protocol version is 1.2 or 1.3.

Stage 04

Check the days-remaining countdown. Flag any certificate under 30 days for immediate renewal and verify the chain shows all intermediate certificates — not just the end-entity cert.

Real-World Stakes: Why Certificate Failures Cost More Than They Should

Certificate expiration is no longer a recoverable inconvenience — it is an immediate availability incident. Modern web browsers and operating systems enforce zero-tolerance security policies that drop customer traffic the second a certificate fails.

Chrome HTTPS-First
Full-screen red interstitial blocks all requests before users can override, crushing conversions instantly.
Apple ATS Enforcement
iOS 17+ and macOS apps hard-block expired or misconfigured certificates with no click-through option.
Search & CrUX Degradation
Downtime over 4 hours triggers soft-404 reclassification, wiping out Core Web Vitals telemetry and rankings.

Automated monitoring closes this gap. Rather than relying on calendar reminders or reactive end-user bug reports, a systematic TLS audit workflow detects renewal windows, CA mis-issuance, protocol downgrades, and SAN coverage gaps before they impact production users.

Diagnostic Coverage: Analysis Vectors vs. Standard Server Defaults

Each scan executes a full TLS handshake against port 443 of the target hostname and parses the complete certificate chain in real time. The four primary evaluation vectors — and their remediation paths — are documented below.

Analysis VectorStandard Server BaselineIncogSay Diagnostic CheckActionable Remedy
Certificate Chain Completeness
RFC 5246 § 7.4.2
Server presents only the end-entity cert and relies on client-side AIA chasing. Fails silently on curl, Android WebView, and API clients that skip AIA resolution. Validates that the complete ordered chain (end-entity → intermediate → root) is served directly in the handshake without external AIA dependencies. Concatenate bundle: cat cert.pem intermediate.pem > fullchain.pem. Configure ssl_certificate fullchain.pem in nginx.
Negotiated TLS Protocol
RFC 8446 (TLS 1.3)
Default configs often enable TLS 1.0–1.3 simultaneously. Legacy clients negotiate down to CBC-mode ciphers vulnerable to BEAST, POODLE, and LUCKY13. Reports the exact negotiated protocol. Flags deprecated TLS 1.0/1.1 as critical findings and confirms TLS 1.3 prioritization in cipher lists. Set ssl_protocols TLSv1.2 TLSv1.3; in nginx or SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 in Apache.
SAN Hostname Coverage
RFC 6125
Wildcards (*.example.com) do not cover apex domains (example.com) unless explicitly declared as a separate SAN. Parses all SAN extensions and flags any mismatch between scanned hostname and covered domains, immediately catching wildcard apex omissions. Reissue certificate with both apex and wildcard SANs: DNS:example.com, DNS:*.example.com.
Expiry & Renewal Window
ASN.1 notAfter
Auto-renewal cron jobs configured for ≤30 days can silently fail if daemon reload hooks error out after cert issuance. Extracts precise expiry from ASN.1 notAfter field. Surfaces a countdown: Warning at <30 days, Critical at <7 days. Configure renewals at ≥45 days. Post-renewal, verify via CLI: openssl x509 -enddate -noout -in cert.pem.

Under the Hood: Technical Execution & Privacy Architecture

A developer performing this verification manually opens a terminal, runs openssl s_client -connect hostname:443 </dev/null, and pipes the PEM dump through openssl x509 -text -noout to parse subject, issuer, SANs, validity window, and cipher suites. While accurate, this workflow takes several minutes per domain and does not scale across a microservice fleet.

IncogSay replaces this with a Cloudflare Workers edge function. When you query a hostname, the request executes at the nearest edge Point of Presence across 300+ global cities:

Phase 1Edge IngressZero logging at edge
Phase 2Port 443 HandshakeDirect TCP TLS stream
Phase 3ASN.1 In-Memory DecodertbsCertificate & SANs
Phase 4JSON Stream & GCIsolate discarded
Privacy Guarantee by Architecture (Zero-Retention): The edge worker executes in an ephemeral V8 isolate with no persistent file system, no database connection, and no analytical logging hooks. The parsed certificate data is serialized to JSON and streamed directly to your browser. Your query is never stored or associated with your IP address, fully adhering to GDPR Article 5(1)(e) storage-limitation requirements by design.

Manual Verification via Command Line Interface (CLI)

The following terminal commands replicate the core verification vectors this scanner automates. All examples use standard Unix utilities available on macOS, Linux, and WSL2 without external dependencies. Replace your-domain.com with your target hostname.

01

Full Certificate Chain Inspection

Chain Integrity

Retrieve and print the complete certificate chain served by the target. The -showcerts flag dumps every intermediate in the handshake — essential for uncovering missing bundle installations.

bash
openssl s_client -connect your-domain.com:443   -servername your-domain.com -showcerts   </dev/null 2>/dev/null   | openssl x509 -text -noout
02

Extract Expiry Date and Days Remaining

Expiry Window

Pipe the live certificate directly from the handshake and compute the exact remaining lifespan in days — perfect for automated cron alerts.

bash
# Print human-readable expiry date:openssl s_client -connect your-domain.com:443 -servername your-domain.com   </dev/null 2>/dev/null | openssl x509 -noout -enddate

# Calculate exact days remaining until expiry (Linux/GNU date):
EXPIRY=$(openssl s_client -connect your-domain.com:443 -servername your-domain.com   </dev/null 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
echo"Days remaining: $(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))"
03

Enumerate All Subject Alternative Names (SANs)

SAN Coverage

Enumerate every domain and IP covered by the certificate to audit wildcard scopes and apex subdomain gaps.

bash
openssl s_client -connect your-domain.com:443 -servername your-domain.com   </dev/null 2>/dev/null   | openssl x509 -noout -ext subjectAltName
04

Confirm TLS 1.3 Negotiation & Reject TLS 1.1

Protocol Hardening

Explicitly test that the modern TLS 1.3 protocol negotiates cleanly and verify that obsolete, vulnerable TLS 1.1 handshakes are rejected.

bash
# Test TLS 1.3 support — should succeed with TLSv1.3:openssl s_client -connect your-domain.com:443 -servername your-domain.com   -tls1_3 </dev/null 2>&1 | grep -E "Protocol|Cipher"# Test deprecated TLS 1.1 — should FAIL on hardened servers:openssl s_client -connect your-domain.com:443 -servername your-domain.com   -tls1_1 </dev/null 2>&1 | grep -E "handshake failure|no protocols available"
05

Verify CAA DNS Records (Authority Authorization)

DNS CAA

Query DNS CAA records to confirm which Certificate Authorities are authorized to sign certificates for your domain.

bash
dig CAA your-domain.com +short

# Expected output for Let's Encrypt authority:# 0 issue "letsencrypt.org"# 0 issuewild "letsencrypt.org"
06

Strict Chain Trust Validation via curl

API Client Parity

curl enforces strict system CA validation without browser AIA fallback. A clean response confirms that API integrations, mobile clients, and backend microservices will connect without SSL errors.

bash
curl -vI --ssl-reqd https://your-domain.com 2>&1   | grep -E "SSL|certificate|issuer|expire|subject"

TLS Handshake & Certificate Authority Chain of Trust Hierarchy

Every SSL diagnostic query performs a live cryptographic handshake with port 443 of the target hostname, evaluating certificate chain integrity, cipher negotiation, and Certificate Transparency logs.

1Ordered Chain Completeness

Validates that the server serves the complete, ordered chain (End-Entity → Intermediate CA → Root CA), preventing mobile and Linux curl clients from failing due to AIA chasing gaps.

2Protocol Version & Forward Secrecy

Verifies TLS 1.3 priority and confirms deprecation of insecure TLS 1.0 and 1.1 protocol suites. Ensures ECDHE key exchange ciphers for forward-secret session security.

3SAN Coverage & Hostname Matching

Extracts all Subject Alternative Names (SANs) from the X.509 v3 extension. Detects common wildcard vulnerabilities where apex domains are omitted from *.domain.com certificates.

4Certificate Transparency (CT) Auditing

Cross-checks issuer fingerprints against public, tamper-evident Certificate Transparency logs to proactively flag unauthorized or rogue CA issuance events.

Free SSL Certificate Checker & TLS Scanner — Key Questions & Technical Answers

Direct, peer-reviewed engineering answers to core deployment, troubleshooting, and compliance questions.

QDoes PCI DSS v4.0 mandate TLS 1.3, and how do I produce compliant evidence for an auditor?

PCI DSS v4.0 (effective March 2024) requires 'strong cryptography' in transit, explicitly deprecating TLS 1.0 and 1.1 and discouraging TLS 1.2 without forward-secrecy cipher suites (ECDHE). While TLS 1.3 is not mandated by name, it is the only protocol version that guarantees forward secrecy by design — all legacy key-exchange modes were removed from the specification. For auditors, documentary evidence must include: the negotiated protocol version, the cipher suite identifier (e.g. TLS_AES_256_GCM_SHA384), certificate validity window, and CA issuer chain. Running this checker against each in-scope hostname and retaining the output as a timestamped artifact satisfies the 'continuous monitoring' intent of PCI DSS Requirements 6.4.3 and 12.3.4.

QMy certificate chain shows a valid end-entity and root cert, but intermediate installation fails on some clients. What causes intermittent chain errors?

This is an AIA (Authority Information Access) chasing failure. Desktop browsers cache intermediate certificates and fetch missing ones from the CA's distribution URL embedded in the AIA extension. Mobile clients and curl on many Linux distributions do not perform AIA chasing — they require the full ordered chain to be presented in the TLS ServerCertificate record. Intermittency occurs because desktop users with a warm cache succeed, while mobile or API clients (strict RFC 5246 consumers) fail with CERTIFICATE_VERIFY_FAILED. Fix: concatenate your end-entity cert and intermediate CA cert into a single bundle (nginx: ssl_certificate fullchain.pem; Apache: SSLCertificateChainFile). Validate with: openssl s_client -connect domain:443 -showcerts — if the output shows only one certificate, the server is misconfigured.

QCan Certificate Transparency logs proactively detect unauthorized certificate issuance for my domain before an attack occurs?

Yes — mis-issuance detection is the primary threat model CT was designed for. Chrome, Safari, and Firefox policy require every publicly trusted CA to submit issued certificates to at least two independent CT logs (e.g. Google Argon, Cloudflare Nimbus) within a defined SCT embedding deadline. A rogue CA or a social-engineering-induced mis-issuance for your domain will appear in CT logs within hours. CAA (Certification Authority Authorization) DNS records provide the complementary preventive control: they instruct CAs which organizations are authorized to issue for your domain. Deploy both — a 'issue' CAA record restricting issuance to approved CAs, and continuous CT monitoring via crt.sh or Facebook's CT Monitor. This checker surfaces the issuer fingerprint so unexpected mis-issued certs can be cross-referenced immediately.

QHow does this tool process my query without server-side logging, and what architectural guarantees prevent hostname retention?

Queries are dispatched to a Cloudflare Workers edge isolate that performs a live TLS handshake with the target hostname. The worker executes in a stateless V8 isolate: no request body, no source IP, no target hostname, and no result payload is written to persistent storage, queued for analytics, or forwarded to third-party logging services. The architecture is functionally equivalent to running 'openssl s_client -connect hostname:443' from your own terminal — the connection exits from our edge node, the certificate data is parsed in memory, and the response is streamed directly to your browser. No query history, no user accounts, no persistent state. GDPR Article 5(1)(e) storage-limitation compliance is satisfied by architecture rather than by policy.

Technical & Diagnostic Reference (31 questions)

Reference Archive

•Why does my browser say a site is "Not Secure" even with a padlock?

This can happen with mixed content (loading some resources over HTTP) or an outdated certificate — an SSL checker diagnoses the specific cause.

•Can I check the SSL certificate of a subdomain separately?

Yes, enter the exact subdomain (e.g., shop.example.com) — certificates can differ between a root domain and its subdomains, especially with wildcard vs. single-domain certs.

•What does "SSL chain of trust" mean and why does it matter?

It refers to the certificate being properly linked to a trusted root Certificate Authority; a broken chain can trigger browser warnings even if the certificate itself is technically valid.

•How far in advance should I renew my SSL certificate?

Best practice is renewing at least 2–4 weeks before expiration to avoid downtime, especially since many CAs now issue shorter 90-day certificates.

•Does an SSL checker verify the certificate issuer (CA)?

Yes, it shows which Certificate Authority issued the cert (Let's Encrypt, DigiCert, Sectigo, etc.), useful for verifying authenticity and catching self-signed certs.

•Can free SSL certificates (like Let's Encrypt) be checked the same way?

Yes, an SSL checker treats free and paid certificates identically, verifying validity, expiration, and chain regardless of the issuing authority.

•How do I check if a website's SSL certificate is valid?

Enter the domain into an SSL checker — it instantly verifies the certificate's validity, issuer, expiration date, and whether the chain of trust is complete.

•What happens if an SSL certificate expires?

Browsers show visitors a security warning and block or discourage access, which can hurt trust and traffic; an SSL checker helps you catch expiration before it happens.

•Does having an SSL certificate mean a site is trustworthy?

Not entirely — SSL encrypts the connection, but even phishing sites can have valid SSL certificates, so it should be one signal among several, not the only one.

•How often should I check my SSL certificate status?

Most certificates last 90 days to 1 year, so checking monthly (or setting up expiration alerts) prevents unexpected downtime or browser warnings.

•What's the difference between SSL and TLS?

TLS is the modern, more secure successor to SSL, but 'SSL' is still the common industry term used for both — an SSL checker typically verifies TLS certificates today.

•How does this compare to Qualys SSL Labs?

Qualys SSL Labs offers a deep technical grade (A+ to F) covering cipher strength and protocol support, while a quick SSL checker is faster and better suited for a simple validity/expiration check.

•Can I check the SSL certificate of an internal or private server?

Only if the checker can reach that server's public-facing address; purely internal/private network servers generally require a local tool rather than a web-based checker.

•How do I detect if a certificate is self-signed rather than CA-issued?

An SSL checker flags self-signed certificates specifically, since browsers don't trust them by default and they trigger security warnings for visitors.

•What TLS version should my website be using in 2026?

TLS 1.2 is the minimum acceptable standard, with TLS 1.3 recommended for best security and performance; an SSL checker typically reports which version(s) your server supports.

•Is there a command-line way to check SSL certificates without a web tool?

Yes, 'openssl s_client -connect domain:443' shows certificate details in the terminal, though a web-based SSL checker presents the same data more readably for non-developers.

•Does an SSL checker show if my certificate covers all necessary subdomains?

Yes, it displays the Subject Alternative Names (SANs) on the certificate, letting you confirm whether it's a wildcard cert or only covers specific subdomains.

•What is an SSL checker and why does every website need one?

It's a tool that verifies whether a website's encryption certificate is valid, current, and properly configured — essential for protecting visitor data and maintaining browser trust.

•Why is SSL especially critical for e-commerce and WooCommerce stores?

Payment and personal data transmitted during checkout must be encrypted; an invalid or expired SSL certificate can expose customer data and trigger browser warnings that kill conversions instantly.

•Do healthcare websites have specific SSL requirements?

Yes, healthcare sites handling patient data typically need to meet HIPAA-related security expectations, and a valid, properly configured SSL certificate is a baseline requirement for compliant data transmission.

•Is SSL checking part of PCI DSS compliance for businesses accepting payments?

Yes, PCI DSS requires strong encryption for cardholder data in transit, and regularly verifying SSL certificate validity is a standard part of maintaining compliance.

•Why would a law firm's website need a strong SSL setup?

Law firms often handle sensitive client communications and documents through their websites, making certificate validity and proper HTTPS enforcement important for confidentiality and client trust.

•Do SaaS companies need to check SSL across multiple subdomains (app, api, dashboard)?

Yes, SaaS platforms typically run several subdomains for different services, each needing its own valid certificate — an SSL checker should be run against each one individually.

•What is an SSL certificate checker and why is it important?

An SSL certificate checker verifies that a website's HTTPS encryption certificate is valid, not expired, issued by a trusted Certificate Authority (CA), and properly installed. It checks certificate chains, TLS protocol versions (TLS 1.2 / TLS 1.3), cipher suites, and Subject Alternative Names (SANs).

•How to check if an SSL certificate is valid online?

Enter any domain into IncogSay's free SSL checker and click 'CHECK SSL CERTIFICATE'. The tool checks Certificate Transparency logs and live TLS handshake parameters to confirm issuer authority, validity dates, days remaining until expiration, and cipher strength.

•What happens when an SSL certificate expires?

When an SSL certificate expires, web browsers (Chrome, Safari, Edge, Firefox) display severe security warnings ('Your connection is not private' or 'NET::ERR_CERT_DATE_INVALID'), blocking visitors and causing immediate traffic and revenue loss.

•How many days in advance should I renew my SSL certificate?

Security best practices recommend renewing SSL/TLS certificates at least 15–30 days before expiration. Most modern CAs (like Let's Encrypt, Cloudflare, DigiCert) issue 90-day certificates with automated renewal hooks.

•What is a Subject Alternative Name (SAN) in an SSL certificate?

A SAN allows a single SSL certificate to secure multiple domain names and subdomains (e.g. 'example.com', 'www.example.com', 'api.example.com'). Our SSL scanner lists all SANs attached to the certificate.

•How to verify if my site is using TLS 1.3 encryption?

TLS 1.3 provides enhanced security and faster connection handshakes compared to legacy TLS 1.0/1.1 (which are deprecated). IncogSay's SSL cert checker confirms the negotiated TLS protocol version.

•Can an SSL certificate check detect man-in-the-middle attacks?

Yes. An SSL check confirms that the certificate is signed by a root CA in browser trust stores, ensuring traffic between the client and server cannot be intercepted or tampered with.

•Is IncogSay's SSL certificate checker free?

Yes. IncogSay provides a 100% free online SSL checker, SSL cert validator, certificate scanner, and expiration date tool.