I recently installed a self signed SSL cert on one of our nginx webservers. If I attempt to wget a file with --no-check-certificate I receive the errors below. You can reach the site with a browser, the browser will recognize that it is self signed, and the cert displays all of the correct information. It seems based on the message I should find a way to trust the cert locally, but doesn't that defeat the purpose of --no-check-certificate?

$ wget https://www.example.com/index.html --no-check-certificate
--2015-02-20 14:13:58--  https://www.example.com/index.html
Resolving example.com...
Connecting to example.com||:443... connected.
WARNING: cannot verify example.com’s certificate, issued by “/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA”:
  Unable to locally verify the issuer’s authority.
WARNING: no certificate subject alternative name matches
    requested host name “example.com”.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Any ideas would be greatly appreciated.

  • 2
    It's warning about the cert but that isn't preventing it from sending a request - it looks like instead of responding to the HTTP request, the server is cutting off the connection - can you do a packet capture to verify, and maybe look in the server's logs to determine what's going on there? Are you making the exact same request, for /index.html, in the browser? – Shane Madden Feb 20 '15 at 21:15
  • Yes, I am making the same request in the browser. I'll have to wait until Monday to get a packet capture from that server(client's not ours unfortunately). I'll post the packet capture as soon as I can. Thank you for the advice! – Minelr G Feb 20 '15 at 21:44

Looking at the wget's error output and command line, the problem here is not the client-side certificate verification. It seems the server machine rejects the connection. This may be due to wget not presenting a required client certificate to the server (check if your other browser have it), this particular user agent being rejected, etc.

I'd rather check server's log.

| improve this answer | |
  • You were right as the issue was on the server's side. Unfortunately the client seems to have adjusted something over the weekend because the problem has vanished....gotta love those – Minelr G Feb 24 '15 at 15:23

You can try to add some debugging: -S and -d for Server and client headers.

tcpdump is better and will provide the full story, but next best thing is the headers w/o full packet payload.


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.