This error appears when a certificate was signed using a deprecated hash algorithm — most commonly SHA-1, which modern browsers no longer trust for certificate signatures (see our SHA-1 deprecation history for the full background).
The fix
This isn't fixable through configuration — the certificate itself needs to be reissued using a modern signature algorithm (SHA-256 or stronger), which any current CA will use by default. If you're seeing this on a certificate you believe is recent, double check you're not accidentally serving an old, cached certificate file rather than your intended current one.
Why browsers specifically reject certain signature algorithms outright
Browsers maintain a list of signature algorithms (like SHA-1) considered cryptographically too weak for continued trust, covered in more depth in our SSL History category — a certificate signed using one of these deprecated algorithms is rejected outright regardless of how correctly everything else about the certificate is configured.
How to identify and fix the specific weak algorithm causing this error
Checking the certificate's Signature Algorithm field directly (via OpenSSL or a browser's certificate details) identifies exactly which algorithm is flagged as weak — the fix is always reissuing the certificate through your CA using a current, strong signature algorithm like SHA-256, since there's no way to modify an already-issued certificate's signature algorithm after the fact.
Why simply waiting doesn't resolve this error the way it might for other warnings
Unlike an error that resolves itself once a certificate naturally renews, a weak signature algorithm requires the site owner to specifically reissue using a stronger algorithm — the certificate's remaining validity period doesn't matter, since the algorithm itself is what's flagged as unacceptable, not the certificate's freshness.
How to check whether your own certificates might be affected before a browser starts flagging them
Running an SSL scan tool against your own domains proactively flags any signature algorithm concerns before they become an active browser-enforced error, giving you time to reissue on your own schedule rather than reacting to a visitor-reported problem.
Why very old certificates from certain CAs are more likely to still use a deprecated algorithm
A certificate issued years ago, before SHA-256 became the universal default, may still be technically valid by its own expiry date while using an algorithm since deprecated — this is specifically why very long-lived, older certificates deserve a proactive check rather than assuming validity alone means everything is current.
A final note on proactive auditing
If you manage certificates issued more than a few years ago without having specifically verified their signature algorithm since, running a quick audit across your entire certificate inventory catches any lingering weak-algorithm certificates before a browser update starts actively flagging them to your visitors.
What the timeline looked like for browsers phasing out support for weak algorithms
Browser vendors announced SHA-1 deprecation years in advance, covered in detail in our SSL History category, giving the industry a long, clearly telegraphed runway to migrate away from weak signature algorithms before active enforcement began — a proactive, well-communicated transition rather than an abrupt, surprise change.
How to check the specific signature algorithm any certificate currently uses
Running openssl x509 -text -noout against a certificate file, or checking the certificate details view in any browser, shows the Signature Algorithm field directly — a quick, definitive way to confirm whether a specific certificate is affected by this class of issue.
A quick closing checklist
A quick closing checklist covers checking the certificate's signature algorithm field directly, confirming your CA's current default uses a strong algorithm, and reissuing immediately if an older, weak algorithm is found rather than waiting for natural expiry.
How this connects to the broader SHA-1 deprecation story covered in our SSL History category
This error is the direct, practical enforcement mechanism behind the SHA-1 deprecation timeline covered in depth in our SSL History category — understanding that broader history explains why browsers treat this specific issue as non-negotiable rather than a soft warning.