The SSL checker above runs a full diagnostic on any public-facing SSL/TLS certificate and returns a detailed report covering security rating, certificate chain, cipher suites, vulnerability scans, and browser compatibility. Sections below explain how to read each part of the report.
Understanding your SSL Security Rating
Every SSL checker scan produces a letter grade from A+ down to F, alongside a numeric score out of 100.
- An A or A+ means the certificate is correctly installed, uses modern cryptography, and the server has the right security features turned on.
- B-grade certificates are functional but reveal room for hardening.
- C and below usually point to a deprecated TLS version, a missing security feature, or a certificate that’s about to expire.
The score is weighted across five categories:
- Certificate (validity and algorithm)
- Trust (recognized Certificate Authority and chain integrity)
- Protocol (TLS versions supported, deprecated protocols disabled)
- Features (HSTS, OCSP Stapling, Perfect Forward Secrecy, CAA)
- Validity (time remaining before expiration)
Most rating drops come from the Features category. The certificate works, the chain is fine, the protocol is current, but HSTS isn’t configured or a CAA record isn’t published. Those are server-side and DNS-side fixes, not certificate problems.
Reading your certificate details
The SSL checker breaks down every certificate in the chain field by field.
Common Name — the primary domain the certificate is issued for. It must match the URL being checked, or the browser rejects the connection.
Issued By — the issuing intermediate plus the parent Certificate Authority. Recognized names like Sectigo, DigiCert, GeoTrust, or Google Trust Services are trusted automatically. Obscure issuers or anything “self-signed” will trigger a warning.
Valid From / Valid To — the certificate’s validity window. Valid From matters more than people expect: if a server’s clock is wrong or a certificate is installed early, browsers reject it as not yet valid.
Signature Algorithm — modern certificates use SHA-256, SHA-384, or ecdsa-with-SHA256. SHA-1 was deprecated years ago and any certificate still using it should be reissued.
Public Key — RSA 2048-bit or higher is standard. ECC 256-bit is the modern alternative and produces smaller, faster certificates.
SAN (Subject Alternative Name) — additional hostnames the certificate covers. Wildcards like *.example.com cover all single-level subdomains. Multi-domain certificates list each protected hostname here. For DV, OV, or EV certificates, the SAN list defines exactly which domains the cert will validate for.
SSL certificate security features explained
Beyond the certificate itself, the SSL checker reports on a panel of six security features.
OCSP Stapling — the server pre-fetches its own revocation status from the CA and includes it in the TLS handshake on port 443. “Not Supported” adds latency to every connection. Usually a one-line config change in Apache, Nginx, or IIS.
Perfect Forward Secrecy (PFS) — each session uses a unique key, so a future private-key compromise can’t decrypt past traffic. “Not Supported” means recorded sessions could be decrypted retroactively. Enable by preferring ECDHE cipher suites.
Certificate Transparency (CT) — issued certificates are logged to public CT logs, letting domain owners detect misissuance. “Not Supported” on a public cert is unusual.
HSTS (HTTP Strict Transport Security) — a server response header telling browsers to refuse plain HTTP connections. Without HSTS, an attacker can downgrade a visitor from HTTPS and intercept traffic. Add a Strict-Transport-Security header in the web server config.
Certificate Revocation Status — the checker queries OCSP and CRL to confirm the cert hasn’t been revoked. “Good” = active. “Revoked” = browsers will reject it, reissue immediately. “Unknown” on CRL is common and not a problem if OCSP returns Good.
DNS CAA Record — a DNS record listing which Certificate Authorities may issue certificates for the domain. Without one, any CA could technically issue a cert. Add a CAA record at the DNS provider listing your CAs.
TLS vulnerability scan results
Five named TLS vulnerabilities are scanned for. Most servers patched years ago, so the SSL checker usually confirms the all-clear.
Heartbleed (CVE-2014-0160) — an OpenSSL memory-read bug that exposed private keys. “Safe” means the server runs a patched OpenSSL build.
POODLE (CVE-2014-3566) — a padding-oracle attack against SSLv3. “Safe” means SSLv3 is disabled.
BEAST (CVE-2011-3389) — a TLS 1.0 cipher block chaining flaw. “Safe” means TLS 1.0 is disabled or the server uses non-vulnerable cipher suites.
ROBOT (CVE-2017-13099) — Return Of Bleichenbacher’s Oracle Threat. An RSA padding flaw that resurfaced in many vendor implementations. “Safe” means the server doesn’t expose vulnerable key exchange.
Ticketbleed (CVE-2016-9244) — F5 BIG-IP-specific memory disclosure via TLS session tickets. “Safe” means no unpatched F5 device.
Cipher suites and protocol support
The SSL checker groups supported cipher suites under TLS 1.3, TLS 1.2, and Weak.
- TLS 1.3 has a small list of strong-by-design suites.
- TLS 1.2 cipher quality varies, which is why each suite is enumerated individually.
- The Weak column flags deprecated protocols or ciphers that should be disabled: SSLv3, TLS 1.0, TLS 1.1, RC4, 3DES, and any NULL or EXPORT cipher.
Cipher suite names follow a predictable structure. In TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:
- ECDHE is the key exchange (providing Perfect Forward Secrecy)
- ECDSA is the signature algorithm
- AES_256_GCM is the symmetric cipher
- SHA384 is the hash function
Both 128-bit and 256-bit AES are safe.
Certificate chain validation
The report shows the full certificate chain as three tiers:
- Server certificate
- Intermediate certificate
- Root certificate
Each tier is signed by the one above it, and the chain must terminate at a root the browser already trusts.
“Chain Complete” means browsers can walk from server to root without issue.
“Incomplete” means one or more intermediates are missing from what the server sends, so browsers can’t link the certificate back to a trusted root and visitors see a security warning.
Incomplete chains are one of the most common SSL installation problems, and the SSL checker flags them at the top of the report. The fix is almost always to reinstall using the full chain bundle the CA provides. Server-specific paths differ: Apache uses a chain file directive while Nginx expects a fullchain.pem. IIS handles chain rebuilds through the certificate import wizard.
Checking SSL certificate expiration
The SSL checker shows expiration in two places: the top summary displays days remaining and the Valid To date, and each certificate in the chain shows its own validity window.
Under CA/Browser Forum Ballot SC-081v3, public SSL/TLS certificate lifetimes are being phased down. As of March 15, 2026, maximum validity dropped from 398 days to 200 days. It falls to 100 days from March 15, 2027, and to 47 days from March 15, 2029.
With a 200-day certificate, monthly checks plus a reminder at the 30-day mark work. By the time 47-day certificates arrive, manual renewal is impractical. The standard answer is ACME-based automation, which lets the server request and renew certificates without manual intervention.
Browser compatibility — when it matters
The SSL checker tests the certificate against 13 browser and device combinations. Modern browsers (Chrome 80+, Firefox 80+, Safari 14+, Edge 80+, Opera 70+, iOS 15+ Safari, Android 10+) should always show Supported on a current certificate.
Older mobile platforms like Android 5–7 and iOS 12 often show partial support. Whether that matters depends on the audience. Legacy desktop browsers like Internet Explorer 10 and 11 almost always fail on modern certificates because they don’t speak TLS 1.2 by default. A 9/13 score with all modern browsers green is normal in 2026.
When to run an SSL check
A single check after installation isn’t enough. Run the SSL checker:
- After installing a new certificate
- 30 days before expiration on a 200-day cycle
- After every renewal or reissue
- After a server migration or IP change
- After switching Certificate Authorities
- After moving to a wildcard or multi-domain setup
- After enabling HSTS, OCSP Stapling, or any TLS config change
Frequently Asked Questions
Monthly is a reasonable baseline. With 200-day certificates now the maximum, set a hard reminder to run a full check 30 days before expiration. Run an extra check after renewals, since chain bundle mistakes are the most common post-renewal problem.
Copy Link
Aim for an A or A+. A B works in every browser, but the gap usually points to fixable issues. Most rating drops trace back to two items the SSL checker flags in the security features panel: a missing HSTS header or an unconfigured CAA record. Neither requires touching the certificate.
Copy Link
Your server isn’t sending all the intermediate certificates browsers need. The short fix: Apache uses SSLCertificateChainFile or a combined bundle, Nginx expects a fullchain.pem file, and IIS rebuilds the chain through the certificate import wizard.
Copy Link
No, public checkers can’t reach internal hosts behind firewalls. From a machine on the same network, run openssl s_client -connect host:443 -servername host for equivalent output. The OpenSSL command-line tool ships with most Linux distributions and is available for Windows.
Copy Link
Yes. It reads whatever certificate the server presents, from Sectigo, DigiCert, GeoTrust, RapidSSL, Thawte, GoGetSSL, Let’s Encrypt, Google Trust Services, and others. SSL Dragon’s SSL certificate catalog covers six of those CAs side by side.
Copy Link
HSTS is a server response header, not part of the certificate. The cert can be perfectly valid while HSTS stays unconfigured. Add it in the web server config: Apache uses Header always set Strict-Transport-Security, Nginx uses add_header Strict-Transport-Security.
Copy Link