ERROR: cannot verify api.example.com's certificate, issued by 'CN=Example Private CA':

The host name and the issuer's distinguished name change with every site. GnuTLS builds of wget (Debian) report the same failure as "ERROR: The certificate of '<host>' is not trusted."

What it means

wget's OpenSSL backend could not verify the server certificate, whose issuer is quoted after "issued by". The indented line wget prints next gives the OpenSSL reason; "Unable to locally verify the issuer's authority" means the issuer is not in the local CA bundle and the server did not send a certificate that leads to one. wget aborts with exit status 5.

Why it happens

• The issuer is a private or company CA

  common

  If the quoted issuer is your organisation's CA or a tool such as a Kubernetes or Vault CA, its root is not in the public bundle on this machine.

• The server omits its intermediate

  common

  If the issuer is a public intermediate ("R13", "GTS CA 1C3", "Sectigo RSA Domain Validation…"), the server did not send it; OpenSSL cannot connect the leaf to a trusted root without it.

• A TLS-inspecting proxy issued the certificate

  occasional

  An issuer name belonging to a security vendor or your company, on a public website, means a proxy is re-signing traffic. Its root must be installed on the machine running wget.

• The CA bundle is out of date

  rare

  Systems that have not updated ca-certificates for years can lack roots that newer public certificates chain to.

How to fix it

1. 1.

   Read the indented reason line

   The line below the ERROR tells you which of the OpenSSL checks failed, and therefore whether to fix trust, the server's chain, or dates.

   ERROR: cannot verify api.example.com's certificate, issued by 'CN=Example Private CA':
     Unable to locally verify the issuer's authority.     <- issuer unknown: CA or chain problem
     Self-signed certificate encountered.                 <- server certificate is self-signed
     Issued certificate has expired.                      <- date problem

2. 2.

   Point wget at the CA

   Pass the root (or a bundle) with --ca-certificate, or set ca_certificate in ~/.wgetrc or /etc/wgetrc.

   wget --ca-certificate=/opt/certs/corp-root-ca.pem https://api.example.com/
   echo 'ca_certificate = /opt/certs/corp-root-ca.pem' >> ~/.wgetrc

3. 3.

   Install the root into the system bundle

   OpenSSL-based wget reads the distribution bundle, so adding the root there fixes wget, curl and most other tools on the machine at once.

   # Ubuntu / Alpine
   sudo cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt && sudo update-ca-certificates
   # RHEL / Fedora
   sudo cp corp-root-ca.pem /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust

4. 4.

   Server owners: serve the full chain

   When the issuer is a public intermediate, configure the server with the leaf followed by the intermediate certificates.

   # Server side: serve leaf + intermediates
   cat api.example.com.crt intermediate.crt > fullchain.pem

5. 5.

   Temporary diagnostic: skip the check once

   --no-check-certificate confirms whether the download would otherwise work. It accepts any certificate, including an attacker's, so do not use it for anything you execute or trust.

   # Diagnostic only
   wget --no-check-certificate -O /dev/null https://api.example.com/

← Browse the full signature error database