How healthy are your domain's signatures?
Enter a domain and our server inspects its TLS setup the way a strict client would: the certificate chain and its signature algorithms, protocol versions, lifetimes and readiness for what comes next — condensed into a grade from A+ to F, with a badge you can put in a README.
This check runs from our server: the domain name you enter is sent to ecdsa.com and we connect to that domain's port 443. Nothing else is collected.
What gets checked
Signature algorithms
Which algorithm signs the certificate and what key it certifies — ECDSA curve, RSA size, Ed25519, or a post-quantum ML-DSA — and whether any broken hash (SHA-1, MD5) is still in play.
Certificate chain
The chain exactly as the server serves it: does every issuer → subject link match, is an intermediate missing, is the leaf self-signed.
Protocol versions
Whether the handshake reaches TLS 1.3, and — with a separate deliberately old-fashioned handshake — whether deprecated TLS 1.0/1.1 are still accepted.
Lifetimes and rotation
Expiry, days remaining, and lifetime against the shrinking CA/Browser Forum limits (200 days from March 2026, 47 by 2029). Short lifetimes earn praise: they signal automated rotation.
How the grades read
- A+TLS 1.3, a modern key, a short-lived certificate, nothing to fix
- Asound configuration with at most cosmetic notes
- Bworks fine, one or two things worth cleaning up
- Cseveral real deductions — plan the fixes
- Dserious problems accumulating
- Fat least one disqualifying defect: expired or SHA-1-signed certificate, RSA below 2048, or TLS 1.0 accepted
The grading is deterministic — the same configuration always earns the same letter. Results are cached for an hour; every report page has a Re-check button that bypasses the cache.
Want to look inside a certificate by hand? The Certificate Decoder decodes any PEM or DER locally in your browser. For the background on why algorithms are graded the way they are, start with ECDSA vs RSA.