Ignoring SSL certificate errors in wget is sometimes used when automation needs to download content from development, lab, or internal HTTPS servers that do not present a certificate trusted by public certificate authorities. Allowing transfers to continue despite validation failures keeps non-sensitive jobs running while infrastructure catches up with properly issued certificates.

$ wget https://www.simplified.guide
--2021-03-29 11:09:07--  https://www.simplified.guide/
Resolving www.simplified.guide (www.simplified.guide)... 127.0.0.1
Connecting to www.simplified.guide (www.simplified.guide)|127.0.0.1|:443... connected.

ERROR: cannot verify www.simplified.guide's certificate, issued by ‘CN=mkcert name@hostname (Your Name),OU=name@hostname (Your Name),O=mkcert development CA’:
  Unable to locally verify the issuer's authority.

ERROR: certificate common name ‘*.simplified.guide’ doesn't match requested host name ‘www.simplified.guide’.

To connect to www.simplified.guide insecurely, use `--no-check-certificate'.

During an HTTPS request, wget validates the server certificate chain against a local store of trusted certificate authorities and compares the certificate subject or subject alternative names with the requested hostname. If any part of this verification fails, wget aborts the transfer and prints a diagnostic error that often suggests adding the --no-check-certificate option or adjusting the configuration in ~/.wgetrc.

Bypassing verification removes an important security control, especially when traffic crosses untrusted networks or when credentials or sensitive data travel inside the same connection. Limiting the bypass to single commands, keeping changes in per-user configuration instead of system-wide files such as /etc/wgetrc, and reserving this behaviour for controlled environments reduces the risk of man-in-the-middle attacks.

Steps to bypass SSL certificate validation in Wget:

  1. Run wget against an HTTPS URL that currently produces a certificate error to confirm the failure state.
    $ wget https://www.example.com
    --2025-01-10 10:00:00--  https://www.example.com/
    Resolving www.example.com (www.example.com)... 127.0.0.1
    Connecting to www.example.com (www.example.com)|127.0.0.1|:443... connected.
    ERROR: cannot verify www.example.com's certificate, issued by 'CN=example.com development CA':
      Unable to locally verify the issuer's authority.
    To connect to www.example.com insecurely, use `--no-check-certificate'.

    Diagnostic output confirms that certificate verification fails and that wget suggests the --no-check-certificate option.

  2. Repeat the download with the --no-check-certificate option to bypass SSL certificate validation only for this invocation.
    $ wget --no-check-certificate https://www.example.com
    --2025-01-10 10:01:00--  https://www.example.com/
    Resolving www.example.com (www.example.com)... 127.0.0.1
    Connecting to www.example.com (www.example.com)|127.0.0.1|:443... connected.
    WARNING: cannot verify www.example.com's certificate.
    HTTP request sent, awaiting response... 200 OK
    Length: 33214 (32K) [text/html]
    Saving to: ‘index.html’
    
    index.html           100%[===================>]  32.4K  --.-KB/s    in 0s
    
    2025-01-10 10:01:01 (120 MB/s) - ‘index.html’ saved [33214]

    Per-command use of --no-check-certificate keeps insecure behaviour limited to specific downloads instead of affecting every wget invocation.

  3. Add or update the per-user configuration file ~/.wgetrc to disable certificate checks persistently only for the current account, if that behaviour is acceptable for the environment.
    $ printf 'check_certificate = off\n' >> ~/.wgetrc

    Disabling certificate checks in configuration increases exposure to man-in-the-middle attacks and hostname spoofing, especially on untrusted networks.

    On Windows the per-user configuration file is commonly read from %USERPROFILE%\.wgetrc.

  4. Run wget again on the same HTTPS URL without --no-check-certificate to confirm that the configuration change allows the transfer while still printing a warning.
    $ wget https://www.example.com
    --2025-01-10 10:02:00--  https://www.example.com/
    Resolving www.example.com (www.example.com)... 127.0.0.1
    Connecting to www.example.com (www.example.com)|127.0.0.1|:443... connected.
    WARNING: cannot verify www.example.com's certificate.
    HTTP request sent, awaiting response... 200 OK
    Length: 33214 (32K) [text/html]
    Saving to: ‘index.html.1’
    
    index.html.1         100%[===================>]  32.4K  --.-KB/s    in 0s
    
    2025-01-10 10:02:01 (115 MB/s) - ‘index.html.1’ saved [33214]

    Expected behaviour: the message changes from a fatal ERROR to a non-fatal WARNING while the content downloads successfully.

  5. List the downloaded files or inspect the most recent one to verify that the expected content was saved despite the certificate warnings.
    $ ls -lh index.html*
    -rw-r--r-- 1 user user 33K Jan 10 10:01 index.html
    -rw-r--r-- 1 user user 33K Jan 10 10:02 index.html.1

    Presence of the downloaded files with non-zero sizes confirms that wget completed the transfers while ignoring certificate errors.

Discuss the article:

Comment anonymously. Login not required.