Signature Algorithm Checker

Check the signature algorithm used by SSL certificates

About Signature Algorithm Checker

Certificate signature algorithms define how a certificate's content is cryptographically signed by the issuing CA. Modern certificates should use SHA-256 or stronger hash algorithms combined with RSA, ECDSA, or Ed25519 signatures. Our Signature Algorithm Checker retrieves the algorithm details and OID from a server's certificate and evaluates its cryptographic strength against current best practices.

How to Use

1Enter the domain name whose certificate signature algorithm you want to check.
2Click "Check" to retrieve and analyze the signature algorithm details.
3Review the algorithm name, OID, strength rating, and security recommendation.

Use Cases

•Verify that certificates use SHA-256 or stronger signature algorithms
•Identify certificates still using deprecated SHA-1 signatures
•Audit certificate chains for consistent signature algorithm strength
•Ensure compliance with CA/B Forum and browser vendor requirements

Frequently Asked Questions

SHA-256 with RSA or with ECDSA is the floor that everything else should be measured against, and Ed25519 is better than either where it is supported. What matters is that SHA-1 must not appear at all: it has practical collision attacks, which is why browsers and certificate authorities have spent years retiring it and why a certificate still signed with it will eventually be rejected outright. MD5 is in the same category and has no defensible use in a certificate.

SHA-1 is vulnerable to collision attacks — researchers demonstrated a practical SHA-1 collision in 2017. All major browsers now reject SHA-1-signed certificates and mark them as insecure.

The Object Identifier (OID) uniquely identifies the signature algorithm in the certificate. For example, 1.2.840.113549.1.1.11 represents sha256WithRSAEncryption. Each algorithm has a distinct OID defined by standards bodies.

Yes, and it is one of the few places where a genuinely broken primitive still appears in production. Because a signature covers the certificate's bytes, an attacker who can find two certificates producing the same signature under a broken hash can substitute their own version and it verifies. That collision has been demonstrated in practice, which is why SHA-1 certificates are treated as needing replacement rather than merely dated.

The signature algorithm is what the issuing CA used to sign this certificate; the key algorithm is what kind of key the certificate carries. They are independent, and the confusion causes real mistakes — a certificate can hold a strong 2048-bit RSA key while being signed with SHA-1, which is a weak combination despite the impressive key size. This page reports the signature algorithm, and the key-strength pages cover the other half.

It is cryptographically sound with no practical attack known, so it is not a vulnerability. It is graded acceptable rather than strong mostly because there is little reason to choose it: SHA-256 is as fast or faster in hardware and has far more deployment support. If you hold SHA-224 certificates, there is no urgency — reissue for consistency and future-proofing, not because anything is broken.

Because the certificate is signed when it is issued, by the authority, before it ever reaches your server. You cannot change that by reconfiguring anything at the serving end — only reissuing produces a different signature algorithm. If you want SHA-256 or better, the action is to request a new certificate from an authority that signs that way, then deploy it.

Reissue it, and confirm the deployed copy afterwards. The old certificate keeps working in most clients until policy deadlines force the issue, so it fails quietly and then suddenly — the failure mode that catches teams out. Order the replacement well ahead of any announced distrust date, and verify externally what the server serves, since renewal succeeding on disk proves nothing about deployment.

How the Algorithm Is Read

A certificate's signature algorithm is an object identifier that no one reads directly, so this page resolves it to a readable name, grades the hash it uses, and explains what that grade means for forgery resistance.

1Retrieve the live certificate and read its signature algorithm identifier. This is the algorithm the issuing CA used to sign it, which is not the same as the algorithm of the public key it contains — a common and consequential distinction.
2Resolve the identifier to a name across RSA, ECDSA and EdDSA families — SHA-256 with RSA, SHA-384 with ECDSA, Ed25519 and the rest. Unrecognised identifiers are reported as unknown rather than guessed at.
3Grade by hash strength — very strong for SHA-512 and Ed448, strong for SHA-256, SHA-384 and Ed25519, acceptable for SHA-224, weak for SHA-1, insecure for MD5 and MD2 — and recommend a migration wherever the grade is below strong.

The hash is what matters for forgery, not the key size, which is why SHA-1 signatures are a live problem on certificates with perfectly strong keys. Reissuing changes the signature algorithm and not the key, so the remediation is always a new certificate.

Tips & Best Practices

•Use strong signature algorithms (SHA-256, SHA-384, SHA-512)
•Verify signature algorithm meets your security requirements
•Avoid weak algorithms (MD5, SHA-1) for certificate signatures
•Monitor signature algorithm usage across your certificate infrastructure

Technical Details

Algorithm: Certificate signature algorithm identification and analysis
Security: Algorithm security assessment and recommendations
Standards: NIST and CA/Browser Forum algorithm requirements
Output: Signature algorithm details with security assessment