SSL Inspector
Analyze SSL/TLS certificates, protocol support, and security posture for any domain.
What is an SSL Inspector?
An SSL inspector analyses the TLS (Transport Layer Security) configuration of a website. It examines the certificate chain, supported protocol versions, cipher suites, key exchange parameters, and revocation status to determine how secure the encrypted connection really is. A misconfigured certificate, untrusted chain, or outdated protocol can expose users to man-in-the-middle attacks, downgrade attacks, or authentication failures.
HTTPSense's SSL Inspector probes every protocol version in parallel — from TLS 1.0 through TLS 1.3 — verifies the chain against the system root store, reports the negotiated ALPN protocol, parses any stapled OCSP response (and fetches one on demand if the server doesn't staple), and detects RFC 7633 Must-Staple certificates. It assigns a security grade from A+ to F based on a weighted analysis of certificate strength, chain trust, protocol support, cipher quality, and revocation status.
How to Use the SSL Inspector
- Enter a domain or URL in the search bar and click Inspect SSL.
- Review the Overview tab for the security grade, score, and a grouped list of errors, warnings, and passed checks.
- Open the Certificate tab to inspect the leaf certificate (subject, issuer, validity, key, signature, Must-Staple flag, SHA-256 fingerprint, SANs) and the full chain from leaf to root.
- Switch to the Protocols tab to see connection facts (host, IP, ALPN, cipher, handshake time, trust status), per-version TLS support, and OCSP revocation results.
- Use the Raw tab to copy or download the full JSON response for scripting or archival.
How the SSL Inspector Works
When you submit a URL or domain, we extract the host and port (defaulting to 443) and open a TCP connection. A real TLS handshake is then performed; we capture the negotiated protocol version, cipher suite, ALPN protocol (h2 or http/1.1), and the full certificate chain returned by the server. The handshake intentionally tolerates untrusted or expired certificates so we can still report on what was served, then verifies the chain ourselves against the system root store and reports the result as a Trust badge.
The leaf certificate is parsed for subject, issuer, validity dates, key algorithm and size, signature algorithm, SHA-256 fingerprint, Subject Alternative Names, and the RFC 7633 Must-Staple TLS Feature extension. Independent probes run for TLS 1.0, 1.1, 1.2, and 1.3 to determine which versions the server still accepts. We parse any OCSP response stapled during the handshake and, if absent, send an OCSP request to the responder URL advertised in the certificate (AIA extension). Findings are evaluated against rules for chain trust, certificate expiry, weak keys/signatures, deprecated protocols, weak cipher suites, OCSP status, and Must-Staple compliance, then summed into a 0–100 score and an A–F letter grade.
SSL is a domain-level concern: results apply to the host, not the URL path.
Key Features
- Parallel protocol probing — Tests TLS 1.0, 1.1, 1.2, and 1.3 simultaneously for fast results with per-version cipher details.
- Chain trust verification — Validates the certificate chain against the system root store and reports the exact failure reason when invalid (expired, unknown CA, hostname mismatch, missing intermediate, self-signed).
- OCSP revocation checking — Parses stapled OCSP responses and falls back to fetching directly from the responder URL listed in the certificate, reporting Good / Revoked / Unknown.
- Must-Staple detection — Identifies RFC 7633 Must-Staple certificates and warns when they are served without a staple.
- ALPN reporting — Shows whether HTTP/2 (h2) or HTTP/1.1 was negotiated during the handshake.
- Certificate chain visualisation — Displays every certificate in the chain with issuer, subject, validity, key algorithm, and SHA-256 fingerprint.
- ECDSA and RSA grading — Correctly grades both ECDSA and RSA certificates, including dual-stack deployments.
- Inspects untrusted certificates — Unlike browsers, we still parse and report on self-signed, expired, or otherwise untrusted certificates so you can debug them.
- Security grade — Provides an A+ to F grade derived from chain trust, certificate, protocol, cipher, and revocation status weighted against industry best practice.
Common Use Cases
- DevOps engineers — Verify certificate deployment after rotation and confirm TLS 1.3 is active in production.
- Security teams — Audit protocol support to ensure deprecated versions like TLS 1.0 are disabled.
- Compliance auditors — Confirm PCI-DSS and HIPAA requirements for strong encryption and valid certificates.
- Site reliability engineers — Monitor certificate expiry dates to prevent unexpected outages from expired certificates.
Frequently Asked Questions
Does this check certificate revocation?
Yes. We parse any OCSP response stapled by the server, and if no staple is present we fetch a fresh OCSP response from the responder URL listed in the certificate (AIA extension). The Protocols tab reports the result as Good, Revoked, or Unknown, along with the response source (TLS staple vs. direct fetch) and validity window. CRL is not consulted; the industry is moving away from CRLs in favour of OCSP and short-lived certificates.
Why does it ding TLS 1.0 and TLS 1.1?
TLS 1.0 and 1.1 are deprecated by the IETF (RFC 8996) and major browsers, and contain known weaknesses. Modern hardening guides recommend TLS 1.2+ only.
What does the “Untrusted” badge mean?
It means the certificate chain returned by the server could not be verified against the operating system’s root certificate store. Common causes: a self-signed certificate, an expired or not-yet-valid certificate, a certificate issued by an unknown CA, missing intermediate certificates, or a hostname that does not match the certificate’s SANs. The exact reason is shown when you hover the badge.
What is Must-Staple?
RFC 7633 lets a certificate require that any TLS handshake using it must include a stapled OCSP response. If the certificate has the Must-Staple flag set but the server does not staple, browsers will reject the connection. We surface the flag in the Certificate tab and warn if a Must-Staple certificate is served without a staple.
Can it check non-default ports?
Yes. Submit the URL with an explicit port — for example https://example.com:8443 — and we will handshake against that port instead of 443.
How is this different from SSL Labs?
Faster, integrated with the Domain Intelligence Report, and it inspects untrusted or expired certificates instead of refusing to connect. We do not currently match SSL Labs in depth (no full handshake-simulator matrix or per-client compatibility table, no per-cipher enumeration, no Certificate Transparency log lookup).
Is it free? Do I need to sign up?
Yes, the SSL Inspector is free with no signup or API key.