ERROR: The certificate of 'api.example.com' is not trusted.

Only GnuTLS builds of wget print this pair of lines. OpenSSL builds (Ubuntu 22.04 and later, Alpine, Fedora's wget 1.x) report the same situation as "ERROR: cannot verify <host>'s certificate, issued by '…'" followed by "Unable to locally verify the issuer's authority."

What it means

GnuTLS, the TLS library Debian builds wget with, could not verify the server's certificate, so wget refuses to download. This first line is generic; the line wget prints right after it names the actual reason, most often "doesn't have a known issuer" (no path to a trusted root) or "has expired". wget exits with status 5 (SSL verification failure).

Why it happens

• The certificate comes from a private CA

  common

  Company, lab and Kubernetes certificates chain to roots that are not in Debian's ca-certificates bundle; GnuTLS reports that as an unknown issuer.

• The server does not send its intermediate certificate

  common

  GnuTLS does not download missing intermediates. A server configured with only the leaf certificate fails here even though browsers, which cache and fetch intermediates, show the site as secure.

• A TLS-inspecting proxy re-signs the connection

  occasional

  Corporate proxies present certificates issued by their own root. Unless that root is installed in the system bundle on this machine (or container), every HTTPS download fails.

• The system has no CA bundle

  occasional

  Minimal Debian and Ubuntu images do not include ca-certificates. Then even well-known public sites are "not trusted".

How to fix it

1. 1.

   Read the line that follows

   The second ERROR line is the real diagnosis. "doesn't have a known issuer" points to a CA or chain problem; "has expired" and "is not yet activated" point to dates; "owner does not match hostname" to a name mismatch.

   wget -O /dev/null https://api.example.com/ 2>&1 | grep '^ERROR'
   # ... is not trusted.
   # ... doesn't have a known issuer.   <- chain/CA problem
   # ... has expired.                   <- date problem

2. 2.

   Tell wget which CA to trust

   --ca-certificate takes a PEM file with one or more CA certificates; ca_certificate in ~/.wgetrc or /etc/wgetrc makes it permanent. --ca-directory works with a hashed certificate directory.

   wget --ca-certificate=/opt/certs/corp-root-ca.pem https://api.example.com/
   
   # permanently, for this user or system-wide (/etc/wgetrc)
   echo 'ca_certificate = /opt/certs/corp-root-ca.pem' >> ~/.wgetrc

3. 3.

   Install the CA into the system bundle

   On Debian and Ubuntu, certificates placed in /usr/local/share/ca-certificates with a .crt extension are added to /etc/ssl/certs/ca-certificates.crt by update-ca-certificates, which GnuTLS reads by default.

   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt
   sudo update-ca-certificates
   # minimal images: install the bundle first
   apt-get install -y --no-install-recommends ca-certificates

4. 4.

   Server owners: send the full chain

   If only one certificate is in the handshake and its issuer is an intermediate CA, configure the server with the full-chain file.

   # Server side: count the certificates in the handshake (1 = leaf only)
   openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null 2>/dev/null \
     | grep -c 'BEGIN CERTIFICATE'

5. 5.

   Temporary diagnostic: skip the check once

   --no-check-certificate shows whether anything other than trust is wrong. It disables all verification, so a proxy or attacker could silently replace what you download; never use it for installers or scripts.

   # Diagnostic only: proves the download works when trust is ignored
   wget --no-check-certificate -O /dev/null https://api.example.com/

← Browse the full signature error database