What CertGrade is

A free, open-source TLS and web-security scanner. Enter a domain, get a one-page report covering certificates, TLS protocols and ciphers, modern protocol features, HTTP security headers, cookies, DNS-side records (CAA, DNSSEC, SPF, DMARC, MTA-STS, DANE), hosting location, and more. Two letter grades summarize the picture: one for TLS, one for headers.

The closest comparisons are SSL Labs and securityheaders.com — CertGrade aims for parity with both in one report, plus a few sections neither has (hosting jurisdiction, multi-vantage DNS, CT-derived subdomain discovery, RDAP).

Security is full of tradeoffs

This is the design principle most security scanners get wrong: every configuration choice is a tradeoff, and reducing it to a red/green flag treats operators like they're either careless or ignorant. Most of the time they're neither — they're balancing compatibility, operational risk, cost, and exposure against the same threat model the scanner is checking.

A few real examples from this report:

• TLS 1.0 still enabled. Reflexive answer: bad, deprecated, broken. Real answer: a hospital running medical equipment that can't speak TLS 1.2 may keep TLS 1.0 active on a specific listener because replacing the equipment costs millions and the alternative (disconnect them from the network) is worse for patient care. The right action depends on context.
• No DNSSEC. Reflexive answer: enable it. Real answer: DNSSEC is hard to roll back, breaks badly if misconfigured, and most modern threats are mitigated by HTTPS + HSTS without it. Banks tend to enable it; ad-tech usually doesn't. Both are defensible — different threat models.
• No CSP. Reflexive answer: missing critical defense. Real answer: CSP is the hardest header to ship without breaking production pages. A bad CSP rollout takes a site down. The right cadence is Report-Only mode for weeks, then enforce.

CertGrade flags the findings, but every "How to fix" panel includes a Why this configuration sometimes exists note describing the legitimate reasons an operator might have made the choice you're looking at. Read it before assuming the site you're scanning is "broken."

What it's for

Three audiences in mind:

• Operators. Run a scan, get copy-paste config snippets for NGINX, Apache, Caddy, Cloudflare, certbot, and major frameworks. Fix what matters; skip what doesn't apply.
• Security folks (auditing or testing). Everything SSL Labs and securityheaders.com give you, plus the bits they miss (DNS- side records, hosting jurisdiction, CT-derived subdomain enumeration).
• Anyone learning network security. The report explains what each section means, why it matters, and what the tradeoff is when the "secure" answer isn't applied. The goal is for a junior engineer scanning a few real sites to come away understanding TLS, not just able to memorize the right answers.

How it works

Every scan runs from scratch — no caching, no permalinks, no user accounts. The report streams progressively so you don't wait 30 seconds staring at a blank page; sections fill in as their underlying scans complete. Geolocation data comes from MaxMind GeoLite2 and ipinfo.io; Certificate Transparency history is mined from crt.sh.

What it isn't

• Not a pentest. CertGrade looks at TLS and headers, not application logic. A site can get A+ here and still have an SQL injection in its login form.
• Not multi-region. Scans run from one set of servers in Romania. The Worldwide DNS Resolution section shows what resolvers elsewhere see, but the TLS handshake itself is from one origin.
• No history. Each scan is fresh; there's no record of what your site looked like last week. (If you want trending, scan via the /api/scan JSON API and store the results yourself.)

Learn

Plain-English walk-throughs of the concepts behind each section live at /learn. First article up: How DNS actually works — what happens between typing a URL and getting a response, plus Traffic Manager / GSLB and anycast.

Contact

Built by @vlad610.