Wget reports that a certificate is signed using an insecure algorithm because it strictly rejects legacy hash functions like SHA-1. To resolve this, you can either update the server's SSL certificate to use a modern standard such as SHA-256 or configure Wget to accept the certificate with specific flags, though updating the certificate is the secure long-term solution.
Understanding the Security Warning
Whenwget attempts to download a file from an HTTPS URL, it performs a TLS handshake to verify the identity of the remote server. Part of this verification involves checking the digital signature on the certificate. Modern versions of wget, particularly those built against recent OpenSSL libraries, enforce strict security policies. They reject certificates that use weak cryptographic hashes, most commonly SHA-1, which is considered vulnerable to collision attacks.
This error does not mean your connection is being intercepted by a man-in-the-middle attacker. Instead, it indicates that the website administrator has not updated their SSL/TLS configuration in years. The browser might still load the page due to more lenient security models or cached trust stores, but command-line tools prioritize security over convenience. If you see messages referencing "insecure algorithm" or "SHA-1," the root cause is the cryptographic strength of the certificate itself, not your local network configuration.
Immediate Workarounds for Testing
If you need to access the content immediately and cannot contact the website administrator, you can bypass the check. However, these methods reduce security and should only be used for trusted internal sites or temporary testing. Never use these workarounds for sensitive data transfers involving personal or financial information. The most common flag to disable certificate verification entirely is--no-check-certificate. This tells wget to ignore all errors related to the certificate chain and signature algorithm.
wget --no-check-certificate https://example.com/file.zip
Another option involves specifying a less secure protocol version, but this is generally discouraged. Older advice suggests using --secure-protocol=SSLv3 or TLSv1, but SSLv3 is known to be vulnerable to the POODLE attack. It is safer to stick to disabling the specific algorithm check if possible, rather than downgrading the entire protocol. If you must downgrade, ensure you are using at least TLS 1.2, though wget often handles protocol negotiation automatically based on what the server supports.
The Recommended Fix: Update the Certificate
The permanent solution requires action from the server administrator. They must generate a new private key and certificate signing request (CSR) using a strong hash algorithm, such as SHA-256 or SHA-384. The certificate authority (CA) will then issue a new certificate signed with this stronger algorithm. For self-signed certificates, the generation command typically looks like this:openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes -keyout key.pem -out cert.pem
Once the new certificate is installed on the web server (such as Nginx or Apache), wget will verify it successfully without any additional flags. This ensures that future downloads are protected against tampering and meet modern security standards. You can verify the change by running wget again after the deployment.
Using Curl as an Alternative
Sometimes, switching tools provides a different user experience regarding error handling. WhilecURL also respects security policies, its default behavior can sometimes be more forgiving depending on how it was compiled and configured. However, modern cURL versions also reject SHA-1 certificates by default.
If you prefer cURL, you can use the -k or --insecure flag to skip verification, similar to wget's approach.
curl -k https://example.com/file.zip -o output.zip
Both tools require similar administrative attention to fix the underlying issue. For more details on troubleshooting connectivity issues with these tools, you might find Troubleshooting curl not working on an RHEL8 Server helpful for diagnosing broader network problems. Additionally, if you are trying to capture the filename during download, How to 'Catch' the Downloaded Filename using wget and cURL Commands? explains how to manage output naming conventions effectively.
Verifying the Certificate Algorithm
Before changing settings, confirm that the certificate is indeed using a weak algorithm. You can inspect the certificate details usingopenssl directly.
openssl s_client -connect example.com:443 -showcerts
Look for the "Signature Algorithm" field in the output. If it says sha1WithRSAEncryption, the certificate is the source of the problem. If it says sha256WithRSAEncryption or higher, the issue may lie elsewhere, such as missing intermediate certificates in your system's trust store. In cases where intermediate certificates are missing, you can specify them explicitly using the --ca-directory or --ca-certificate flags in wget.
Frequently Asked Questions
Is it safe to use --no-check-certificate?
No, it disables critical security checks and exposes you to potential man-in-the-middle attacks. Use it only for trusted internal resources or when debugging non-sensitive connections.
Why do browsers allow SHA-1 certificates but wget does not?
Browsers have historically maintained compatibility with older sites while displaying warnings, whereas command-line tools often enforce stricter defaults to encourage security upgrades.
Can I fix this by updating my local openssl library?
Updating your local library may tighten security further, making the error appear sooner. The fix must come from the server side issuing a new certificate.
Does this error affect FTP downloads?
No, this error is specific to HTTPS/SSL connections. FTP uses different authentication mechanisms and does not rely on X.509 certificates in the same way.
What is the minimum secure hash algorithm?
SHA-256 is the current minimum standard for RSA signatures. SHA-1 is deprecated and should never be used for new certificates.