Weak Key Detector

Detect weak cryptographic keys in SSL certificates

About Weak Key Detector

Cryptographic key strength is critical to SSL/TLS security. Our Weak Key Detector analyzes the keys in your server's certificate chain, checking for known weak key sizes, deprecated algorithms, and insecure configurations. It supports RSA, ECDSA, and Ed25519 keys and flags any key that falls below modern security standards.

How to Use

1Enter the domain name you want to test in the input field.
2Click "Check" to analyze the server's cryptographic keys.
3Review each check result and follow recommendations for flagged issues.

Use Cases

•Audit key strength across all certificates in your infrastructure
•Identify certificates using deprecated RSA-1024 or SHA-1 signatures
•Ensure compliance with industry standards like PCI DSS and NIST
•Verify key strength before deploying new certificates to production
•Compare key strength across multiple domains and environments

Frequently Asked Questions

RSA keys below 2048 bits and ECDSA keys below 256 bits are considered weak by modern standards. The tool flags these as warnings and recommends upgrading.

Yes, weak keys can be factored or broken with modern computing power. RSA-512 can be cracked in hours, and RSA-1024 is considered borderline with nation-state resources.

Yes, ECDSA and Ed25519 keys provide equivalent security to RSA with much smaller key sizes. ECDSA-256 is comparable to RSA-3072, and Ed25519 offers excellent security with fast performance.

For current sizes, no, and the practical break is far beyond reach. What a small key does instead is erode margin: the difficulty of factoring falls predictably as the modulus shrinks, so a 1024-bit key buys an adversary a meaningful reduction in work at a price of no operational benefit whatsoever. The finding is about removing that margin, not about an imminent compromise.

Because of how signatures cover a certificate. A signature is computed over the certificate's bytes, so if two different certificates can be crafted that produce the same signature under a broken hash, an attacker can substitute their own version and it verifies. That is exactly the chosen-prefix collision demonstrated against SHA-1, and it is why the hash matters more here than almost any other single field.

The absence is reported rather than treated as a pass. Without the extension there is nothing constraining what the certificate's key may be used for, so a key intended only for signing could be repurposed. Modern issuance sets it by default; its absence points at either an unusual internal CA or a manually built certificate, both worth confirming as intentional.

No, and it cannot. What is published on the wire is the public half; the private key never leaves your server, so no external checker can assess it. This page judges what clients actually receive. To check that your private key matches its certificate and is stored safely, use the checksum and import pages with the files held locally.

Unlikely, and worth checking rather than assuming. Renewal sometimes changes more than the dates: a different product tier, a different authority path, or a narrower key usage extension can alter the verdict. Compare the certificate details before and after with the decoder page, and confirm the deployed file is the one you issued rather than a stale copy that renewal left in place.

What the Detector Examines

Retrieve the certificate and run four checks over it, each producing its own verdict. Together they cover the four ways a certificate's key material is commonly found wanting, and each finding names its own remedy.

1Key size against the algorithm. RSA has its own floor and elliptic curves are judged by curve rather than bits, so the comparison is made within each family instead of treating a 256-bit curve key as small.
2Signature algorithm. SHA-1 and MD5 signatures are deprecated and reported as such, because a certificate signed with a broken hash can be forged by producing a second certificate that verifies against the same signature.
3Key usage, read from the extension when present. A certificate carrying a narrower usage than intended restricts what it can do — and one with no key usage extension at all is reported, since absence leaves usage unconstrained.
4Validity dates, because a weak key that is about to expire is still an emergency. Expired or near-expiry findings appear alongside the cryptographic ones rather than replacing them.

All four run over the certificate actually served. The detector is single-purpose; for the full strength picture per algorithm, the dedicated RSA, ECDSA and Ed25519 pages go deeper on one family each.

Tips & Best Practices

•Use RSA keys of at least 2048 bits, preferably 4096 bits
•Consider ECDSA keys (P-256 or P-384) for better performance and security
•Replace weak keys immediately — they provide no real security
•Monitor key strength across your entire certificate infrastructure

Technical Details

Algorithms: RSA, ECDSA, Ed25519 key strength analysis
Minimum: RSA 2048-bit, ECDSA P-256, Ed25519
Recommended: RSA 4096-bit, ECDSA P-384
Output: Key strength assessment with upgrade recommendations