Automation that pulls files over HTTPS using wget often encounters certificate errors when servers use self-signed or privately issued certificates. Providing a specific .crt file that represents the correct certificate authority allows non-interactive downloads to remain fully validated instead of disabling checks with --no-check-certificate. Centralising this configuration simplifies maintenance for scripts, cron jobs, and other tooling that rely on consistent TLS behaviour.

Under Linux, wget normally relies on the system CA bundle maintained in directories such as /etc/ssl/certs to verify remote HTTPS endpoints. A custom CA or server certificate in .crt format can be supplied either per-invocation with --ca-certificate or persistently through the personal .wgetrc file, adding that trust anchor to wget's internal store. Combining a dedicated certificate directory with a single configuration directive keeps the TLS trust surface explicit while leaving the rest of the system untouched.

Any additional trusted certificate broadens the set of endpoints that TLS handshakes will treat as valid, so incorrect or compromised .crt files can enable transparent man-in-the-middle attacks. Misconfiguring certificate paths in .wgetrc may cause every HTTPS transfer to fail with messages such as ERROR: cannot verify or silently fall back to weaker behaviour depending on the build. Storing the custom .crt securely, validating its subject and fingerprint out-of-band, and documenting which hosts depend on it reduces risk and makes rollback straightforward.

Steps to configure wget with a CRT file:

  1. Open a terminal on the Linux host that performs HTTPS downloads with wget.
    $ whoami
    alice
    $ wget --version | head -n 3
    GNU Wget 1.21.2 built on linux-gnu.
    ##### snipped #####

    Version output confirms that wget is installed and built with HTTPS support.

  2. Create a dedicated directory in the home directory for custom certificate authorities.
    $ mkdir -p "$HOME/certs"
    $ ls -ld "$HOME/certs"
    drwxr-xr-x 2 alice alice 4096 Dec  8 10:15 /home/alice/certs

    Directories such as /home/*user*/certs keep private CA material separate from system-wide stores under /etc/ssl/certs.

  3. Copy the trusted .crt file into the custom directory with a descriptive name.
    $ cp internal-root-ca.crt "$HOME/certs/internal-root-ca.crt"
    $ ls -l "$HOME/certs/internal-root-ca.crt"
    -rw-r--r-- 1 alice alice 2049 Dec  8 10:16 /home/alice/certs/internal-root-ca.crt

    Using explicit names such as internal-root-ca.crt or lab-ca.crt simplifies later audits and rollbacks.

  4. Inspect the .crt file with OpenSSL to confirm subject, issuer, and expiration date.
    $ openssl x509 -in "$HOME/certs/internal-root-ca.crt" -noout -subject -issuer -enddate
    subject=CN = Internal Root CA, O = Example Corp, C = US
    issuer=CN = Internal Root CA, O = Example Corp, C = US
    notAfter=2035-12-31T23:59:59Z

    Fingerprints and subjects should match values obtained through a trusted out-of-band channel before adding the certificate to any trust store.

  5. Perform a one-off HTTPS download using the new certificate to confirm that the TLS handshake succeeds.
    $ wget --ca-certificate="$HOME/certs/internal-root-ca.crt" https://internal.example.com/status
    --2025-12-08 10:20:01--  https://internal.example.com/status
    Resolving internal.example.com (internal.example.com)... 10.0.0.10
    Connecting to internal.example.com (internal.example.com)|10.0.0.10|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 1234 (1.2K) [text/plain]
    Saving to: ‘status’
    
    status                   100%[==========================>]    1.21K  --.-KB/s    in 0s
    
    2025-12-08 10:20:01 (10.5 MB/s) - ‘status’ saved [1234/1234]

    Trusting an incorrect or tampered .crt file may cause wget to accept malicious HTTPS endpoints and expose credentials or downloaded data.

  6. Persist the certificate path in the personal .wgetrc so future downloads automatically trust the CA.
    $ printf "ca_certificate = %s\n" "$HOME/certs/internal-root-ca.crt" >> "$HOME/.wgetrc"
    $ tail -n 5 "$HOME/.wgetrc"
    ##### snipped #####
    ca_certificate = /home/alice/certs/internal-root-ca.crt

    The ca_certificate directive affects only wget and only for the account that owns the corresponding .wgetrc file, leaving system-wide TLS settings unchanged.

  7. Verify that subsequent wget invocations succeed without specifying the --ca-certificate option.
    $ wget https://internal.example.com/status
    --2025-12-08 10:22:15--  https://internal.example.com/status
    Resolving internal.example.com (internal.example.com)... 10.0.0.10
    Connecting to internal.example.com (internal.example.com)|10.0.0.10|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 1234 (1.2K) [text/plain]
    Saving to: ‘status.1’
    
    status.1                 100%[==========================>]    1.21K  --.-KB/s    in 0s
    
    2025-12-08 10:22:15 (9.87 MB/s) - ‘status.1’ saved [1234/1234]

    Successful verification is indicated by the absence of ERROR: cannot verify messages, an expected HTTP status such as 200 OK, and the desired file saved to disk.

Discuss the article:

Comment anonymously. Login not required.