A certificate that uses the SHA-1 hashing algorithm in its digital signature. In PKI, signature strength matters because a weak hash can undermine certificate trust and allow collision attacks that make distinct certificates appear legitimate. Older environments may still depend on them when SHA-2 support is missing.
What SHA-1 Signed Certificates Are
SHA-1 signed certificates are X.509 certificates whose digital signatures were created with SHA-1. They still identify a certificate, but the signature algorithm is the weak point: if the hash function is no longer collision-resistant enough, the trust chain can be undermined.
The practical meaning is simple. A certificate may still parse, validate, and appear normal while relying on a signature method that modern PKI no longer considers strong enough for long-term trust. That makes the signing algorithm, not just the subject or key size, part of the certificate’s security posture.
Why SHA-1 Became a Certificate Problem
SHA-1 was once widely used because it was interoperable and efficient, but collision attacks changed the risk profile. In a certificate context, a collision can let an attacker craft two different objects that produce the same digest, which is exactly the kind of weakness that trust systems are designed to avoid.
That is why deprecation happened in stages. Browsers, operating systems, and certificate authorities moved away from SHA-1 as stronger hash families became the baseline for public trust. The issue is not that every SHA-1 certificate is instantly malicious, but that the algorithm no longer offers the margin of safety expected for modern assurance.
For background on public trust expectations and issuance norms, the CA/Browser Forum provides the baseline requirements that helped drive SHA-1 out of public TLS issuance.
Where SHA-1 Signed Certificates Still Show Up
These certificates are most often encountered in legacy systems, older enterprise PKI deployments, embedded products, and long-lived internal environments that were not fully migrated when SHA-2 became the standard. In those environments, compatibility pressure can keep an outdated certificate chain alive longer than it should be.
That lingering support is not just a hygiene issue. It can create operational drag when modern clients reject the chain, and it can mask a broader cryptographic debt problem, where aging certificate profiles, outdated CAs, and weak signing algorithms coexist.
NIST SP 800-57 Key Management is the clearest external reference for thinking about algorithm strength, cryptoperiods, and when weak cryptographic choices should be retired.
What SHA-1 Means for Trust and Replacement Planning
In practice, SHA-1 signed certificates are a migration signal. They indicate that certificate lifecycle management has not fully caught up with current cryptographic expectations, and that trust may depend on outdated assumptions about signature resistance.
The right replacement is usually a SHA-2 or stronger certificate profile aligned to the environment’s trust requirements. For machine-facing and internal PKI, that often means modernizing certificate automation, renewal, and inventory so the weak signatures are removed before they become an outage or audit finding.
For a broader view of certificate lifecycle concerns, see NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide, which connects certificate strength with lifecycle automation and renewal discipline.
Risk and Threat Considerations
SHA-1 signed certificates create a trust weakness because collision resistance is part of what makes a signature meaningful. If the signing algorithm is weak enough, an attacker may be able to abuse certificate equivalence assumptions, especially where legacy validation logic or stale trust stores are still in use.
Failure mechanism: A weak hash allows crafted collisions, which can reduce confidence that the signed certificate is uniquely bound to its intended contents. In older or mismanaged environments, that weak binding can become an avenue for impersonation, downgrade, or trust abuse.
Impact: The result can be broken certificate trust, failed validation in modern clients, or, in the worst case, acceptance of an illegitimate certificate chain that should not have been trusted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 4.2 — Algorithm Selection and Cryptoperiods | Addresses choosing and retiring cryptographic algorithms and their lifetimes. |
| Recommendation — Replace SHA-1 certificates with stronger algorithms and align renewal timing to current cryptographic guidance. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Requires strong cryptographic practices for trust and protection of digital communications. |
| IA-5 — Authenticator Management | Supports lifecycle management of authenticators and related cryptographic material used for trust. | |
| Recommendation — Review certificate signing algorithms and remove weak cryptographic dependencies from trust chains. Inventory certificate authenticators and retire SHA-1 signed certificates from active use. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Covers selection and use of cryptographic controls for information protection. |
| Recommendation — Standardize on stronger certificate-signing algorithms and document migration away from SHA-1. | ||
Practitioner Guidance
What to watch for: Any certificate inventory that still contains SHA-1 signatures should be treated as remediation backlog, not as a benign legacy detail. The main question is whether the certificate is still relied on by any production path, device, or integration.
Practitioner takeaway: If SHA-1 is still present anywhere in a trust chain, the real task is not to preserve the certificate, but to plan and validate the migration path that removes it without breaking dependent systems.
Related resources from NHI Mgmt Group
- Why do expired DSCs create operational risk even when a document was signed while the certificate was valid?
- How should organisations verify digitally signed documents after a certificate has expired?
- What breaks when foreign organisations try to manage signed transactions without a proper digital certificate process?
- What happens when a self-signed certificate is used on Windows without importing the root CA certificate on client machines?
