Learn Wget - HTTPS, TLS & Certificates

#Introduction

In episode 12 you controlled the network path — proxy, IP protocol, bind address, and DNS. Now wget knows where the packets must go. The next question is far more important: who are you actually talking to? When wget targets https://, there's one layer at work before a single byte of HTTP moves — that layer is TLS.

Imagine sending an important letter through a public post office. The envelope can be sealed, but who guarantees it reaches the right address and isn't opened along the way? TLS answers two things at once: encryption (no one can read the contents) and authentication (you're sure the other party is the real server). Episode 13 dissects this most often under-appreciated security layer.

#HTTPS: HTTP Inside a TLS Tunnel

HTTPS isn't some magical new protocol — it's HTTP running inside a tunnel of TLS. Before any request is sent, wget and the server perform a TLS handshake: exchange parameters, agree on the protocol version, verify identity, then build the session's encryption keys. Once the tunnel is formed, HTTP runs normally inside it, invisible to anyone in the middle.

First, confirm that your wget build has TLS support:

wget --version

Look at the final part of the output, which mentions OpenSSL or GnuTLS. Almost all modern distributions have it, but very minimal builds sometimes don't — and without TLS support, all of https:// will never work.

#Certificate Verification by Default

The core of TLS authentication is the digital certificate — a document issued by a Certificate Authority (CA), a party trusted to "sign" a server's identity. wget, when built with SSL support, verifies certificates by default: checking that the certificate chain ends at a CA trusted by the system, that the validity period is still active, and that the host name matches what's stated in the certificate. It's analogous to an ID card — you never meet the issuer, but because the signature can be verified back to an institution you trust, the card is trusted.

If verification fails, wget refuses before sending any data, with a message like this:

ERROR: cannot verify example.com's certificate, issued by 'CN=...':
  Unable to locally verify the issuer's authority.
To connect to example.com insecurely, use '--no-check-certificate'.

Note the most important thing: wget refuses before a single byte is sent, and exits with exit code 5 (SSL verification failure). That's not a bug — it's a feature. Your data is never sent to an unverified party.

#CA Bundle and --ca-certificate

Default verification uses the CA bundle installed on the system. For special environments — corporate internal CAs, staging servers, or isolated networks — you can point to a specific bundle or directory:

wget --ca-certificate=/etc/ssl/certs/ca-certificates.crt \
  https://api.internal.example.com/

wget --ca-directory=/etc/ssl/certs https://api.internal.example.com/

--ca-certificate points to a single bundle file; --ca-directory points to a directory containing many certificates. The cleanest approach remains installing the internal CA into the system directory with update-ca-certificates, so wget trusts it without extra flags in every script.

#--secure-protocol: Locking the TLS Version

TLS has several generations, and not all of them are fit for use. Old versions like SSLv2, SSLv3, and TLS 1.0 are considered obsolete and almost always rejected by modern servers — in many recent builds they've even been removed from OpenSSL. The --secure-protocol option locks in the allowed version:

wget --secure-protocol=TLSv1_2 https://api.example.com/

wget --secure-protocol=TLSv1_3 https://api.example.com/

Valid values include auto (default, picks the best), TLSv1_2, and TLSv1_3. If you point to a protocol the build doesn't support, wget refuses with a message that the protocol isn't available — a choice that's actually healthy, because you'd rather know the policy is stuck than silently fall down to a weak version. Setting TLSv1_2 or TLSv1_3 explicitly removes ambiguity in environments with strict security policies.

#Why --no-check-certificate Is Dangerous

--no-check-certificate turns off certificate verification. It's the fastest way to make the error above disappear — and also the fastest way to open the door to man-in-the-middle. Without verification, anyone on the network path — an ISP, a dishonest proxy, or an attacker on public wifi — can insert a fake certificate and read the entire contents of the transfer as if they were the real server.

# JANGAN lakukan ini di produksi
wget --no-check-certificate https://api.example.com/secure

Imagine locking your front door and then giving the key to everyone on the street. --no-check-certificate is exactly like that: the encryption is still there, but the key is shared with anyone. If an endpoint forces you to use this option, the right question isn't "how do I turn off verification?", it's "why doesn't this server have a valid certificate?".

#Client Certificates: Mutual TLS

Verification so far is one-way — the client verifies the server. There's a stricter scheme, mutual TLS (mTLS), where the server also verifies the client. The server asks the client to prove its identity with a client certificate. wget sends it via --certificate and --private-key:

wget --certificate=client.pem --private-key=client-key.pem \
  https://api.example.com/secure

• --certificate=client.pem — the client certificate (identity + public key).
• --private-key=client-key.pem — its paired private key.

If the private key is encrypted, wget prompts for the passphrase interactively. If the format is DER rather than PEM, indicate it via --certificate-type=DER and --private-key-type=DER. mTLS is used for strict service-to-service communication — between microservices, or connections from CI to an internal registry. Identity can be checked in both directions, and that's a strength and a responsibility: a leaked private key is a forged ID card.

#HSTS: Enforcing HTTPS

There's a subtle hole in HTTPS: the first connection to a site can still fall back to HTTP if an attacker intercepts it first — an attack known as a downgrade on first visit. HSTS (HTTP Strict Transport Security) closes that hole. When a server answers with the Strict-Transport-Security header, wget records that host and, for a certain period, automatically upgrades http:// to https://:

wget --hsts-file=$HOME/.wget-hsts https://example.com/

The HSTS database file is stored at a location you point to — by default ~/.wget-hsts — and the --no-hsts option turns off the entire mechanism. It's like a security guard taking notes: "from now on, this building requires the encrypted corridor." HSTS turns a one-time decision into a remembered policy — layered defense on top of ordinary certificate verification.

#Closing

Episode 13 opened the hood on wget's HTTPS security layer: understanding that HTTPS is a TLS tunnel over HTTP, CA certificate verification that's active by default and exit code 5 on failure, controlling the CA bundle with --ca-certificate and --ca-directory, locking the TLS version with --secure-protocol, avoiding --no-check-certificate for strong reasons, sending client certificates with --certificate and --private-key for mutual TLS, and leveraging HSTS to enforce HTTPS.

The key thing to remember: certificate verification isn't a formality — it's a checkable identity. Turning off verification doesn't make the problem disappear; it just sweeps it under the rug, and anyone passing by can take your data.

In episode 14, we close the security loop from the other side: authentication and security best practices — how to store credentials without leaking them through shell history, the role of the .netrc file, and the checklist every download must go through. See you there!