Trouble getting started - Site Cannot be Reached

My domain is:

I ran this command:

It produced this output:

  • My webserver is unresponsive to web traffic, “Site Cannot Be Reached”

My web server is (include version):

  • nginx/1.14.0 (Ubuntu)
  • node v12.10

The operating system my web server runs on is (include version):
Ubuntu server 18 LTS

My hosting provider, if applicable, is:
AWS Lightsail

I can login to a root shell on my machine (yes or no, or I don’t know):
Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.31.0


Hi all!

I had a web server up and running that was Ubuntu Server 18 LTS, Nginx, and Node. So I had multiple webservers running on different ports using node, and nginx was handling the web traffic by using proxy_pass’s.

Everything was running smoothly, and then I ran the steps on certbot’s instructions. It seemed really straight forward, it even detected that I was running multiple sites and asked if I wanted to get ssl’s for them all, followed by asking if I would like to redirect all http traffic to https. I thought that this was neat and would save me a lot of work so I did it. After it said that I was done, I checked my site, www.mrdev.io, and the page was unresponsive. I tried with the rest of the sites and they are all unresponsive.

Nginx is running, Node webservers are also running, what could be going wrong? Is there a command to undo what the bot did, and if so, is there any harm in running it if I were to try again by manually configuring?

Thank you for taking the time to look into my issue.

1 Like

Hi,

Did you open security groups with port 443 access?
Port 443 is closed for me.

Also, you might need to check your Nginx virtual host files. Certbot might changed some of them so it’s not responding (since proxy doesn’t work)

Thank you

1 Like

That’s interesting… I thought I opened up the ports, sudo lsof -i -P -n | grep LISTEN yielded this:

nginx     3459            root    8u  IPv4  35172      0t0  TCP *:80 (LISTEN)
nginx     3459            root    9u  IPv4  35173      0t0  TCP *:443 (LISTEN)
nginx     3461        www-data    8u  IPv4  35172      0t0  TCP *:80 (LISTEN)
nginx     3461        www-data    9u  IPv4  35173      0t0  TCP *:443 (LISTEN)

But https://www.yougetsignal.com/tools/open-ports/ say’s it’s not open… I’ll look into this and the virtual hosts files though.

1 Like

Best command to check what ports are open is:

netstat -plnt

Also check that ufw is set to allow HTTPS/443 traffic if it hasn’t already been set.

Since you’re running multiple vhosts, check each port 80 server block as the redirect is usually added in there.

Also LE likes to create separate files for port 443 so ensure that those server blocks are configured properly.

1 Like

this is the output from netstat -plnt

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -                              
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                             
tcp6       0      0 :::22                   :::*                    LISTEN      -                   
tcp6       0      0 :::3000                 :::*                    LISTEN      -                   
tcp6       0      0 :::3001                 :::*                    LISTEN      -
1 Like

Okay so it’s listening on 443 for sure. Should have had you run that as sudo so you can get the pid/app listening on each port. I normally elevate to root when I’m troubleshooting so I don’t need sudo. But I also see it’s listening on port 53, which makes me think you’re also running your own DNS service off your server as well. I personally leave the DNS hosting to cloudflare.

Next is to check your port 443 server block configurations. Also to see what redirect lines were thrown into your port 80 server blocks.

1 Like

So I realized what was wrong with my server blocks, I wasn’t listening on port 80 for those, so I changed it and got the http traffic back. The thing is script asked if I wanted to redirect that, and I said yes, so I thought it would handle that.

To be honest, I’m not sure what’s on port 53 - the process says “systemd” and I vaguely remember something about PM2 running that. As you can probably tell, I’m new to this and I’m trying to figure this part out.

The port 443 server blocks were written by the bot, and they seem fine. I checked port 443 on https://www.ipfingerprints.com/portscan.php and it said it’s filtered, and I’m still getting “The page took too long to respond” when I force https. Any advice?


edit:
Just decided to try again, so I used certbots delete command and deleted the cert, deleted the sites in nginx’s sites available and started over. Redid the server blocks to direct http traffic to a certain port- looked something like this:

server {
	listen 80;
	server_name www.abc.com abc.com;

	location / {
		proxy_pass http://localhost:3000/;
	}
}

Simple, but it pointed to the correct port for the subdomains. Then I went back and created used the certbot to generate new certs, and I used the redirect option again. This removed the listen 80; and turned it into this:

server {
	server_name www.mrdev.io mrdev.io;

	location / {
		proxy_pass http://localhost:3000/;
	}

	listen 443 ssl; # managed by Certbot
	ssl_certificate /etc/letsencrypt/live/mrdev.io/fullchain.pem; # managed by Certbot
	ssl_certificate_key /etc/letsencrypt/live/mrdev.io/privkey.pem; # managed by Certbot
	include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
	ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
	if ($host = www.mrdev.io) {
		return 301 https://$host$request_uri;
	} # managed by Certbot

	if ($host = mrdev.io) {
		return 301 https://$host$request_uri;
	} # managed by Certbot
	listen 80;
	server_name www.mrdev.io mrdev.io;
	return 404; # managed by Certbot
}

Now I’m back at square one, with the same problem as before…

1 Like

I see the issue.

Listen 80;

Is still there. Just on the bottom server block.

Those if statements are throwing things off & making it more complicated than it needs to be. Remove those & the return 404 line.

If all your sites have certs, set a global redirect to https (or just have the return 301 line on each site’s port 80 block). I personally prefer to have my port 80 blocks set first, then the port 443 block after. It doesn’t matter because the force redirect will issue a new request, but it’s an organization thing in my own head. The following article will help you do your own force redirect instead of using the LE automated script.

EDIT:
Also check the SSL options & dhparams file. You want to make sure you are set to disable everything below TLSv1. 2 & make sure insecure ciphers are disabled. I use apache and have had to remove the line that calls on the apache config because it wasn’t as secure as my own global config.

It hasn’t been updated in a while, but I have edited the cipher list by removing all rsa entries & adding the following to the end:

:!RSA:!SHA1

You can test your server’s security & compatibility here:

https://www.ssllabs.com/ssltest/

2 Likes

After some troubleshooting, I finally figured it out.

The issue was with Amazon Lightsail. What was happening was that even though I was allowing SSL through Nginx and UFW, I did not allow it through the instance control panel under the “networking” tab…

I really do appreciate all the effort you put in looking into this for me though.

1 Like

Glad you figured it out! I do suggest confirming your SSL settings for security purposes, which is the main reason for my edit. Everything else is good.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.