Inspect any website's SSL/TLS certificate, check expiration dates, view cipher suites, and verify the complete certificate chain. All from your iPhone.
Download Free on the App StoreSSL Inspector and all 19 tools are free. No ads, no account required.
PingKit connects to any server over TLS and retrieves the full certificate details. You see the issuer, subject, validity period, serial number, signature algorithm, subject alternative names, and the negotiated TLS version and cipher suite. The complete certificate chain is displayed so you can verify that intermediate certificates are correctly configured.
View the full X.509 certificate including issuer, subject, SANs, serial number, signature algorithm, and key size. Everything you'd see in a browser's certificate viewer, but faster to access.
See the exact expiration date and days remaining for any certificate. Catch expiring certificates before they cause downtime and browser security warnings for your users.
Check which TLS version and cipher suite the server negotiates. Identify servers still using deprecated TLS 1.0/1.1 or weak cipher suites that pose security risks.
Inspect the entire certificate chain from leaf to root. A missing intermediate certificate is one of the most common SSL configuration errors, and PingKit makes it immediately visible.
Managing websites means managing certificates. Whether you use Let's Encrypt with 90-day certificates, a commercial CA with annual renewals, or a CDN that handles certificates automatically, you need to verify that the right certificate is being served. PingKit lets you check any domain instantly without opening a browser, navigating to the site, and clicking through the certificate viewer.
Weak TLS configurations are a common security finding. PingKit shows you the negotiated TLS version and cipher suite so you can identify servers still supporting deprecated protocols. If a server negotiates TLS 1.0 or uses a cipher suite with known vulnerabilities, you'll see it immediately. This makes quick security spot-checks possible from anywhere.
When users report certificate errors, you need to see exactly what the server is presenting. Is it serving the wrong certificate? Is an intermediate missing? Has the certificate expired? Is the subject alternative name list correct? PingKit answers all of these questions without needing access to the server itself. Connect from your phone and inspect what the server sends.
After renewing a certificate, you need to confirm the new one is actually being served. Check the serial number and expiry date to verify the renewal was deployed correctly. This is especially important with auto-renewal systems like Let's Encrypt or ACME, where deployment can silently fail while the renewal itself succeeds.
SSL Inspector is part of PingKit's broader security and infrastructure toolkit. Pair it with Port Scanner to check which services are exposed on a server, DNS Lookup to verify domain configuration, and WHOIS to check domain registration details. Together, these tools give you a complete picture of any domain's configuration and security posture, all from your iPhone with no command line required.
Most people only think about certificates when something breaks. But a quick certificate check is one of the fastest ways to answer a surprising number of everyday networking and security questions. Here are the situations where we reach for PingKit's SSL Inspector most often.
Before you enter a password, payment details, or anything sensitive, it's worth confirming who actually holds the certificate for that domain. The Inspector shows you the issuer and the exact subject the certificate covers, so you can verify the site is presenting a legitimate, current certificate from a recognized authority rather than something expired, mismatched, or self-signed. Pair this with a quick WHOIS lookup to see who registered the domain and when, and you have a solid first-pass trust check in under a minute.
Certificates expire, and an expired certificate takes a site down hard: every visitor sees a full-page browser warning. The Inspector shows the precise expiration timestamp and the number of days remaining, so you can tell at a glance whether a renewal is overdue or coming up. This is especially handy for Let's Encrypt certificates, which last only 90 days and rely on automation that occasionally fails silently.
When a browser throws a privacy or certificate error, it rarely tells you why in plain terms. Inspecting the certificate directly shows you the actual cause: an expired date, a hostname that isn't in the certificate, an untrusted issuer, or a broken chain. Instead of guessing, you see exactly what the server is presenting and can fix the right thing the first time.
After deploying or renewing a certificate, you need to confirm the server is sending the complete chain, not just the leaf certificate. A missing intermediate is the single most common HTTPS misconfiguration we see. The Inspector walks the full chain from your server's certificate up to the trusted root, so you can confirm every intermediate is in place before users hit a problem. If you're also debugging response headers or redirects, our HTTP analyzer pairs neatly with this check.
Security audits and compliance checklists often require TLS 1.2 or higher and the removal of weak ciphers. The Inspector reports the TLS version and cipher suite the server negotiates, so you can spot a host still accepting deprecated TLS 1.0 or 1.1, or one offering a cipher with known weaknesses. It's a fast way to confirm a server meets a baseline without firing up a laptop.
An SSL/TLS certificate is a small, signed file built on the X.509 standard. It does two jobs: it carries the public key used to encrypt your connection, and it makes a verifiable claim about who controls the server. Here's what each field means, in plain English.
The issuer is the certificate authority (CA) that signed the certificate, such as Let's Encrypt, DigiCert, or Sectigo. Clients trust a small set of root CAs that ship with the operating system. If the issuer chains back to one of those roots, the certificate is trusted automatically.
The subject identifies who the certificate is for. For a public website this is the domain name. Historically the Common Name field held the hostname, but modern clients ignore it for hostname matching.
Every certificate has a "not before" and "not after" date. The connection is only trusted while the current time falls inside that window. Outside it, clients reject the certificate even if everything else is perfect.
The SAN field lists every hostname the certificate is valid for, including wildcards like *.example.com. This is the field clients actually check when matching the hostname you typed against the certificate. A certificate can cover many names at once, which is why the SAN list matters more than the subject for diagnosing mismatches.
Servers rarely present a certificate signed directly by a root CA. Instead, a root signs an intermediate, and the intermediate signs your certificate. That sequence is the chain of trust. A client follows the chain upward until it reaches a root it already trusts. Break any link and trust collapses, which is why the Inspector shows the whole chain rather than just the leaf.
A CA-signed certificate is vouched for by a trusted authority. A self-signed certificate is signed by its own key, so nothing external vouches for it. Self-signed certificates still encrypt traffic, but clients can't verify identity, so they're suited to internal tools and development rather than public sites.
There are a handful of SSL checker apps and web tools out there. Here's an honest look at where PingKit fits, so you can decide whether it's the right tool for what you need.
| PingKit | Typical free SSL apps | Web-based checkers | |
|---|---|---|---|
| Cost & ads | Free, no ads, no account | Often ad-supported or paywalled | Free but ad-heavy |
| Full chain & cipher view | Yes, leaf to root | Usually leaf only | Yes, but desktop-oriented |
| Part of a wider toolkit | 19 tools (DNS, WHOIS, ports, HTTP) | SSL only | Single-purpose page |
| Automated expiry monitoring | Yes, with Guardian Plus | Rare | Sometimes, with paid signup |
We'll be straight about the trade-offs. A dedicated desktop tool or a service like SSL Labs goes deeper on grading and edge-case protocol testing than a phone app needs to. PingKit's goal is different: fast, ad-free, on-demand certificate checks from the device that's already in your pocket, sitting alongside the other 19 tools you reach for when something on the network looks wrong. For most "is this certificate okay right now?" questions, that's exactly the right shape.
When HTTPS breaks, the error message is usually vague. Here's how to read the most common failures and what each one points to. In nearly every case, inspecting the certificate directly turns a guessing game into a clear fix.
The most common and most preventable failure. The Inspector shows the "not after" date and days remaining; if that number is negative, the certificate has lapsed and every client is rejecting it. Renew and redeploy, then re-check the serial number to confirm the new certificate is actually live. To stop this happening again, set up monitoring so you're warned weeks ahead rather than the moment it breaks.
This means the hostname you connected to isn't in the certificate's SAN list. Check the SAN entries the Inspector displays. Often the fix is as simple as the certificate covering example.com but not www.example.com, or a wildcard not reaching the subdomain depth you need. Reissue the certificate with the correct names and the mismatch clears.
If the Inspector shows the chain stopping before it reaches a trusted root, an intermediate certificate is missing or the issuer isn't trusted. Reinstall the full chain (your certificate plus every intermediate, in order) on the server. This is the fix for the classic "works in one place, fails in another" certificate problem.
Browsers are forgiving: they cache intermediates and sometimes fetch missing ones automatically, which masks a server that isn't sending its full chain. Apps and command-line clients usually don't. So a site can look fine in Safari yet fail in your app. The Inspector shows the exact chain the server sends, with no browser magic, so the missing intermediate becomes obvious. Fix the server's chain and both will work.
Self-signed certificates trigger warnings on public sites because no authority vouches for them. The Inspector flags self-signed certificates clearly. If you intended it to be self-signed (internal tooling, a lab device), the warning is expected. If you didn't, the server is presenting the wrong certificate and you should deploy a CA-signed one. If you're chasing down the right host for a domain in the first place, a DNS lookup confirms which server is actually answering for that name.
Open PingKit, go to SSL Inspector, and enter any domain name. PingKit connects to the server, retrieves the full certificate, and shows the issuer, subject, validity dates, serial number, signature algorithm, and the complete chain, along with the negotiated TLS version and cipher suite.
The Inspector shows the exact expiration date and time for any certificate, plus how many days remain. That makes it easy to catch certificates that need renewal soon, including short-lived Let's Encrypt certificates on their 90-day cycle.
A chain links your server's certificate to a trusted root CA through one or more intermediates. If any link is missing, clients show security warnings even when the server certificate itself is valid. PingKit displays the entire chain so you can verify intermediates are configured correctly.
The Inspector reports the TLS protocol version negotiated on connection. Modern sites should use TLS 1.2 or 1.3; if you still see TLS 1.0 or 1.1, the server has known weaknesses worth addressing.
Almost always a missing intermediate. Browsers cache and sometimes fetch intermediates automatically, hiding an incomplete chain that apps and CLI tools reject. The Inspector shows the exact chain the server sends, so reinstalling the full chain fixes both.
The hostname you connected to isn't listed in the certificate's SAN field. Modern clients check SANs only, not the legacy Common Name. The Inspector lists every SAN so you can see exactly which names the certificate covers.
It encrypts traffic fine, but no authority vouches for it, so clients can't verify the server's identity. That's acceptable for internal tools and development, but not for public websites, where browsers show a security warning. PingKit clearly flags self-signed certificates.
Yes. The Inspector connects to any hostname and port, so you can check mail servers (465, 993), APIs on custom ports, or internal services. Just specify the port alongside the hostname.
No. The SSL Inspector and all 19 tools are free, with no ads and no account. Guardian Plus ($4.99/mo or $39.99/yr) adds automated certificate expiry monitoring, 90-day history, and compliance export on top, but every on-demand check is free. You can read more in our guide on how to monitor SSL certificate expiration.
SSL Inspector checks certificates on demand. Guardian Plus monitors your domains automatically and alerts you before a cert expires. Add domains to your watch list and get push notifications on iPhone and Apple Watch when a certificate needs attention.
Learn About Guardian PlusNoxen — our sister Mac app — checks TLS, security headers, and CVE exposure across your full Linux/VPS fleet on a nightly schedule. PingKit handles ad-hoc cert checks; Noxen handles the ongoing fleet.
Visit noxen.app →Download PingKit free and check SSL certificates from your iPhone.
Download Free on the App StoreRequires iOS 17.0 or later.