0

The big picture is I'm trying to setup an SSL connection for a subdomain, if I go to currently if I go to the non-secure url the website works, but if requeset https://sub.domain.com there is no response from the server:

This webpage is not available ERR_CONNECTION_CLOSED

This a multifaceted question, so please let me know if I'd be better off breaking the question down into bite-sized chunks. Also feel free to let me know if any of this would be better on StackOverflow. This is how I view the chain of items that make up the situation:

  1. SSL Certificate Supplied by startssl.com
  2. URL is owned at Godaddy (not by my choice)
  3. A CNAME points to a Microsoft Azure Virtual Machine
  4. The VM is a standard Ubuntu 14.04.2 LTS
  5. Nginx is setup with a reverse proxy to point two urls to separate applications on the same server.
  6. The application is a Meteor App deployed with mup.
  7. The nginx 'vhost' is setup like this to work with meteor/sockets.

I've tried a few ways to setup the SSL and debug it:

  • Following these instructions which has mup (a deployment tool) setup STUD
  • Startssl instructions so setup a cert with nginx
  • In the azure management console I've uploaded the certificate for the "cloud service"

Known Unknowns:

  • Don't know if using Microsoft Azure makes any difference or if it doesn't make a difference because the ubuntu VM is what's being run no matter what IaaS is being used.
  • Don't know where down the line the https request is dropped (e.g. does it get to the VM? Does it get to the upstream nginx proxy server?). The http:// url works fine and I can view the upstream's server's logs but see nothing in the upstream server's logs for the the secure url.
  • A traceroute from my computer of both the secure and unsecure urls both appear to have the same path. Does this mean anything in this context?

Essentially I'm looking for help on how I can try to debug why the secure URL is not found in a linear fashion. Especially in regards to the second unknown, as I currently don't know where the connection is lost / how far the request currently gets down the rabbit hole.

Thanks!

Shwaydogg
  • 131
  • 1
  • 6

1 Answers1

2

Yeah, this is a pretty huge question. In a very general sense, you debug this the same as you do for any other networking-related problem: tcpdump to see whether the packets are getting to where they need to, and whether they've got the contents you'd expect, and then you check the logs on whatever is receiving the packets to see how they're being processed.

Given the nature of the error message, I suspect the connection is being established, and then it's being unceremoniously closed. Being HTTP/HTTPS, I lean towards an nginx misconfiguration which is causing port 443 to not be using SSL. The nginx error log will mention something along those lines.

womble
  • 95,029
  • 29
  • 173
  • 228