SSL certificate checker
Check any site's SSL/TLS certificate: issuer, expiry date, days remaining, chain trust, and the names it covers.
Check a site's SSL certificate
Expired certificates break trust
A web certificate proves a site's identity and encrypts traffic. When one expires or fails to validate, browsers show warnings and captive-portal logins stop working. This checker performs a live TLS handshake and reports exactly what the certificate says.
What this tool gives you
- Issuer, subject, validity window, and the number of days until expiry.
- Chain-trust result, TLS protocol version, and all subject alternative names.
- A safe, read-only check that never inspects private or internal addresses.
X.509 SSL/TLS certificate architecture: how the trust chain works
Modern secure communications rely on the X.509 Public Key Infrastructure (PKI) standard. When a client initiates a TLS handshake with a web server or captive portal gateway, authentication is established through a three-tier cryptographic hierarchy:
Root Certificate Authority
The trust anchor pre-installed in operating system and browser root stores (e.g. DigiCert Global Root CA, ISRG Root X1, GTS Root R1). Root certificates remain offline in high-security HSM facilities.
Intermediate CA
The operational signing authority delegated by the Root CA. Web servers must bundle the Intermediate CA certificate in their TLS configuration to complete the chain of trust to the client.
Server Leaf Certificate
The end-entity certificate bound to your specific domain (e.g. portal.purple.ai). Contains public keys, validity dates, and Subject Alternative Names (SANs).
Why captive portals and guest WiFi networks require valid commercial SSL
In public guest WiFi environments, captive portal gateways intercept client web traffic to present splash pages for authentication, marketing opt-ins, and terms acceptance. Because modern operating systems enforce strict zero-trust network protocols, an invalid or expired SSL certificate will trigger catastrophic guest connection failures:
Critical impact on mobile captive network assistants (CNA):
- Apple iOS Captive Network Assistant (CNA): iOS sends an HTTP probe to
captive.apple.com/hotspot-detect.html. If redirected to an HTTPS captive portal with a self-signed or invalid SSL certificate, iOS terminates the CNA webview with an SSL handshake error, preventing guests from reaching the sign-in page. - Android CaptivePortalLogin: Android devices probe
connectivitycheck.gstatic.com/generate_204. If the portal certificate is untrusted, the system displays a persistent notification stating "Sign in to network (Security error)" and disables internet routing. - Enterprise Walled Garden Bypass: Wireless controllers (Cisco Catalyst, Meraki, Aruba CX, Ruckus SmartZone) require authorized FQDNs in the walled garden access control list. If the SSL redirection domain does not match certificate SANs, browsers block the session with
ERR_CERT_COMMON_NAME_INVALID.
Certificate Authority (CA) comparison for enterprise and captive portal deployments
Choosing the right Certificate Authority ensures seamless mobile device compatibility, reliable automated renewals, and compliance with enterprise security baselines:
| Certificate Authority | Validation Level | Validity | Automation | Recommended Application |
|---|---|---|---|---|
| Let's Encrypt (ISRG) | Domain Validation (DV) | 90 Days | ACME Protocol (Native) | Cloud captive portals, automated web apps, modern APIs |
| DigiCert / GlobalSign | DV, OV & EV | 1 Year (397 Days) | REST API & ACME | Enterprise banking, corporate infrastructure, legacy hardware |
| Sectigo (Comodo) | DV, OV & EV | 1 Year (397 Days) | ACME & SCEP | Large enterprise IT networks, commercial RADIUS servers |
| Cloudflare SSL / GTS | Domain Validation (DV) | 90 Days to 1 Year | Edge Managed (Zero-Touch) | Edge CDN acceleration, global guest WiFi portals |
| AWS Certificate Manager | Domain Validation (DV) | 13 Months | Auto-Renew via Route 53 | AWS CloudFront & ALB hosted captive portal endpoints |
TLS 1.2 vs TLS 1.3: performance and cryptographic differences
Transport Layer Security (TLS) version 1.3 delivers substantial speed and privacy improvements over TLS 1.2 by streamlining the cryptographic handshake:
| Feature & Parameter | TLS 1.2 (RFC 5246) | TLS 1.3 (RFC 8446) |
|---|---|---|
| Handshake Latency | 2 Round Trips (2-RTT: ~100-200ms) | 1 Round Trip (1-RTT: ~30-60ms) / 0-RTT Resumption |
| Key Exchange | Static RSA or Ephemeral DH (DHE/ECDHE) | Strictly Ephemeral (ECDHE / FFDHE) for Forward Secrecy |
| Supported Ciphers | 37+ Cipher Suites (Includes legacy CBC, 3DES, RC4) | 5 Modern AEAD Ciphers (AES-GCM, ChaCha20-Poly1305) |
| Certificate Encryption | Cleartext (Visible in network packet captures) | Fully Encrypted during the handshake phase |
| Captive Portal Impact | Slower splash page rendering on mobile networks | Instant splash screen presentation across Apple & Android |
Common SSL/TLS certificate errors and troubleshooting guide
The requested domain name is not listed in the certificate Subject Alternative Names (SAN) extension. Ensure all portal subdomains and access point FQDNs are covered by wildcard or multi-domain SAN certificates.
The certificate validity timestamp has lapsed. Configure automated ACME renewals to trigger at least 30 days before expiration to prevent sudden venue outages.
The web server is serving the leaf certificate without the Intermediate CA chain. Install the full certificate bundle (fullchain.pem) rather than just the certificate leaf (cert.pem).
The server configuration restricts TLS cipher suites to obsolete algorithms unsupported by modern clients. Enable TLS 1.3 and secure TLS 1.2 AEAD cipher suites.
How Purple automates SSL certificate management for enterprise WiFi
Purple eliminates captive portal certificate maintenance by managing the entire TLS lifecycle in the cloud:
- Automated ACME Certificate Lifecycle: Zero-touch SSL rotation ensures captive portals never expire, maintaining continuous guest access across thousands of venue access points.
- Universal Mobile CNA Compatibility: Pre-validated against Apple iOS, Google Android, Windows, and macOS captive network assistants with 99.99% connection success.
- Cross-Vendor Controller Integration: Seamless HTTPS redirection architecture verified across Cisco Catalyst, Cisco Meraki, Aruba, CommScope Ruckus, Ubiquiti UniFi, and Fortinet.
- Encrypted 802.1X Passpoint Roaming: Deploy Hotspot 2.0 profiles with enterprise-grade WPA3 encryption, eliminating captive portal splash screens entirely for returning visitors.
Related enterprise WiFi and captive portal technical guides
Frequently asked questions
Why does an SSL certificate show 'Chain not trusted' or 'Self-signed certificate in chain'?
A certificate chain error occurs when the web server fails to bundle the necessary intermediate Certificate Authority (CA) certificates or uses a private, self-signed root. Operating systems and browsers maintain a strict store of pre-approved public Root CAs. If the path from the server leaf certificate to a trusted root is broken, browsers display severe security warnings.
How does an expired or invalid SSL certificate cause captive portal guest WiFi login failures?
When a smartphone connects to guest WiFi, its operating system (such as Apple iOS Captive Network Assistant or Android CaptivePortalLogin) opens a sandboxed webview to load the captive portal login page over HTTPS. If the portal's SSL certificate is expired, missing intermediate certificates, or fails hostname matching, the OS aborts the redirection process, trapping the guest without internet access.
What is the difference between single-domain, wildcard, and multi-domain (SAN) SSL certificates?
A single-domain certificate covers exactly one FQDN (e.g. portal.example.com). A wildcard certificate covers all first-level subdomains under a domain (e.g. *.example.com). A multi-domain SAN certificate allows multiple distinct hostnames across different domains to share a single cryptographic certificate, which is ideal for multi-venue enterprise WiFi networks.
Why do Apple iOS CNA and Android CaptivePortalLogin require public commercial CA certificates?
Mobile captive portal assistants do not allow users to bypass SSL certificate warnings or accept self-signed certificates. To protect users from man-in-the-middle attacks on public networks, mobile operating systems immediately terminate captive portal connections that fail public CA root verification.
What is the recommended SSL/TLS certificate renewal timeline and automated rotation strategy?
Industry standard practice (enforced by major browser root programs) recommends automating certificate renewal via the ACME protocol (such as Let's Encrypt or Sectigo ACME) at 60 days of a 90-day validity lifetime. This provides a 30-day buffer to detect and resolve any DNS or renewal automation failures prior to service interruption.
How does TLS 1.3 improve SSL handshake latency and connection security over TLS 1.2?
TLS 1.3 reduces the initial handshake from two round trips (2-RTT) down to a single round trip (1-RTT), cutting connection latency by up to 50%. It also removes legacy, vulnerable cipher suites (such as RSA key exchange, CBC ciphers, and SHA-1) in favour of ephemeral Diffie-Hellman (ECDHE) with authenticated encryption (AES-GCM and ChaCha20-Poly1305).
Eliminate captive portal SSL certificate downtime with Purple
An expired or misconfigured SSL certificate breaks guest WiFi authentication and triggers frightening browser security warnings. Purple manages SSL certificates automatically across all venues with automated renewals, 99.99% uptime, and seamless Apple and Android captive network compatibility.
Book a 20-min demoNetforge Network Multi-Tool
Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.
Download Multi-Tool