wget的--no-check-certificate选项重要性及相关技术疑问

Great questions about wget's certificate checking behavior—let's break them down clearly:

By default, wget verifies the SSL/TLS certificate presented by the target HTTPS server when you initiate a download. Here's a step-by-step breakdown of how the check works:

• When you run wget https://example.com/file, wget establishes a TLS connection with the server. The server sends its digital certificate (which includes details like the domain it's valid for, expiration date, and a signature from a Certificate Authority, or CA).
• Wget then cross-references this certificate against your system's trusted root CA store:
  • On Linux, this is usually the /etc/ssl/certs directory or files managed by ca-certificates.
  • On macOS, it uses the system Keychain Access's trusted roots.
  • On Windows, it relies on the Windows Certificate Store.
• The check covers several critical points:
  • Is the certificate still within its valid date range (not expired or not yet active)?
  • Was it signed by a CA that your system trusts?
  • Does the certificate's domain match the URL you're accessing (either via the common name or Subject Alternative Name fields)?
  • Has the certificate been revoked (some systems check CRLs or OCSP for this, depending on configuration)?
    If any of these checks fail, wget will refuse the connection and throw an error—this is when people often add --no-check-certificate to bypass the verification.

Absolutely—you can’t assume that just because you don’t need the flag, your friend won’t. Here’s why the behavior differs across machines:

• Trusted CA store differences: Your system might have extra CA certificates installed (like a private CA for your company’s internal sites) that your friend’s machine doesn’t. For example, if you’re downloading from an internal HTTPS server signed by your company’s CA, your machine trusts it, but your friend’s won’t—they’d need the flag or to install the CA cert.
• Wget version gaps: Older versions of wget might lack support for newer TLS protocols or certificate types (like ECDSA certificates). If you’re running a recent version that handles the site’s certificate fine, but your friend has an outdated wget, they might hit verification errors that require the flag.
• System clock mismatches: If your friend’s machine has an incorrect system time (way off from the current date), wget will think the site’s certificate is expired or not yet valid—even if it’s perfectly fine. Your machine with correct time won’t have this issue.
• Network interception: Some networks (corporate gateways, public Wi-Fi) use SSL interception to inspect traffic. These networks replace the site’s real certificate with one signed by their own CA. If your machine trusts this interception CA (maybe your IT team installed it), you won’t need the flag—but your friend on a different network (or without the CA installed) will get an error.

内容的提问来源于stack exchange，提问作者jmd_dk