I tried to wget a website, which came back saying:

ERROR: The certificate of ‘website.com’ is not trusted. ERROR: The certificate of ‘website.com’ hasn't got a known issuer.

from one machine, and from another

ERROR: cannot verify website.com's certificate, issued by ‘CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE’: Unable to locally verify the issuer's authority. To connect to website.com insecurely, use `--no-check-certificate'.

As an additional check I used Python's request library to see what it would say:

requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",)

However when the website was loaded in Firefox and Chrome, neither had any issue with the website's certificate. Shouldn't they also be warning me about any issues with the sites SSL certificate?

  • When you look at the certificate, is the domain you are visiting listed in the Subject Alternative Names (SAN) list? The reason I ask is because recently I had a similar issue with curl and I had to add the intermediate certificate in order for curl to properly read it.
    – Jeroen
    Commented Mar 21, 2018 at 7:51
  • I followed [stackoverflow.com/questions/20983217/… (this from another question) white resulted in: verify error:num=20:unable to get local issuer certificate verify return:1 verify error:num=21:unable to verify the first certificate verify return:1 DONE Commented Mar 21, 2018 at 8:10

2 Answers 2


It is not fully clear what your problem exactly is since there are insufficient information to reproduce it. But, assuming that you are using a recent version of wget an requests with support for SNI I would imagine that it is

  • Either the servers certificate is issued by a CA which is trusted by the browser but not by your systems CA store. Chrome and Firefox use a different CA stores than wget or requests. This can happen for example if the servers certificate (as received by the client) was issued by a non-public CA, which is often the case when accessing intranet sites or if there is a firewall employed with SSL interception. Especially on Windows systems it might also happen that the certificate store for wget and requests is simply empty since the systems CA store is not compatible with OpenSSL.
  • Or the site is misconfigured and the server does not send a necessary intermediate certificate. Desktop browsers often work around this problem, other programs don't. Check this site against SSLLabs and look for chain issues.
  • 2
    It was a public website, and tested running on Linux. SSLlabs reported an incomplete chain and no DNS CAA, so looks like this is the issue. Thanks. Commented Mar 21, 2018 at 8:23
  • 6
    @GeorgeBroughton: DNS CAA is not a problem which can cause this (it is only relevant for the CA, not the client) but incomplete chain does. Commented Mar 21, 2018 at 8:35
  • 2
    Just to add. Browsers get around this issue by looking at the Authority Info Access (AIA) extension of the cert, which has a url for the intermediary cert. The Browser then reconstructs the chain to verify. Commented Mar 22, 2018 at 3:06
  • @keithRozario: while some browsers (like Chrome) do it other browsers (like Firefox) don't use AIA. See issue 339324 for some discussion about this where AIA is requested for Firefox but the issue is closed as WONTFIX since Firefox does not want to work around such misconfigurations. Commented Mar 22, 2018 at 5:06
  • @SteffenUllrich so interesting. Thanks, never knew that, I can see their point in not supporting. But lots(!) of websites don't do TLS properly. Commented Mar 22, 2018 at 5:33

Can you try installing certifi, and then use requests? That will use the same Root Certificates as Mozilla, so you should see the same behavior as your browser.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .