Let’s Encrypt problem

sudo lsof -iTCP -sTCP:LISTEN -P

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
lfd 11584 root 4u IPv4 17231 0t0 TCP *:6666 (LISTEN)
memcached 11624 memcached 26u IPv4 17666 0t0 TCP *:11211 (LISTEN)
memcached 11624 memcached 27u IPv6 17667 0t0 TCP *:11211 (LISTEN)
sshd 11650 root 3u IPv4 17700 0t0 TCP *:22 (LISTEN)
mms 11664 root 94u IPv4 18590 0t0 TCP localhost:9850 (LISTEN)
mms 11664 root 138u IPv4 18823 0t0 TCP localhost:43234 (LISTEN)
master 11750 root 12u IPv4 17937 0t0 TCP localhost:25 (LISTEN)
php-fpm 11764 root 8u IPv4 18079 0t0 TCP localhost:9000 (LISTEN)
nginx 29360 root 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 29360 root 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31256 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31256 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31257 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31257 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31258 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31258 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31259 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31259 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31260 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31260 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31261 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31261 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31262 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31262 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31263 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31263 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31264 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31264 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)
nginx 31265 nginx 22u IPv4 88267 0t0 TCP *:80 (LISTEN)
nginx 31265 nginx 23u IPv4 88268 0t0 TCP *:443 (LISTEN)

Doesn’t it look like port 443 is open?

The fact is that attempting to connect times out. That’s separate from whether or not Nginx is listening on the port.

I just executed these commands:

sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

iptables restart

And everything’s the same. I don’t understand anything.

Hi @studios

checking your domain you have created a new certificate - https://check-your-website.server-daten.de/?q=studiosh2o.com#ct-logs

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2020-03-04 2020-06-02 studiosh2o.com - 1 entries duplicate nr. 1
Let’s Encrypt Authority X3 2020-02-13 2020-05-13 studiosh2o.com - 1 entries

So that part has worked. http works - https has only timeouts.

Domainname Http-Status redirect Sec. G
http://studiosh2o.com/ 188.226.194.196 301 https://studiosh2o.com/
Html is minified: 108,54 % 0.040 A
http://www.studiosh2o.com/ 188.226.194.196 301 https://www.studiosh2o.com/
Html is minified: 108,54 % 0.040 A
https://studiosh2o.com/ 188.226.194.196 -14 10.147 T
Timeout - The operation has timed out
https://www.studiosh2o.com/ 188.226.194.196 -14 10.360 T
Timeout - The operation has timed out

There must be a blocking instance.

There must be a blocking instance?

What does that mean? What can I do?

It’s not your configuration that is responsible for this issue. Check it a thousand times and you will get the same results every time.

The internet at large cant see your port (even though you can) because it is being filtered upstream from you. DigitalOcean, LLC.

The only way for you to be certain of this is to CONTACT THEM and ask a few questions.

Rip

It could still be their configuration. For example, earlier they appended a firewall rule, but that wouldn’t stop other firewall rules that matched first.

You can run “sudo iptables-save” to dump all the IPv4 iptables rules.

(Unsure what to do on modern nftables systems.)

@studios, have you looked at the Cloud Firewall configuration?

I followed your suggestion: sudo iptables-save

And everything’s the same. :frowning:

With reference to Cloud Firewall:

Firewall DigitalOcean
You haven’t applied any Firewalls to this Droplet yet.

Works your https internal? What says

curl https://studiosh2o.com/
curl https://www.studiosh2o.com/
curl https://188.226.194.196/

from that machine?

If yes, your configuration works. If not, that’s the first step you have to fix.

And

nginx -T
1 Like

curl https://studiosh2o.com/

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

curl https://www.studiosh2o.com/

Returns all the HTML of the page correctly.

curl https://188.226.194.196/

curl: (51) SSL: certificate subject name ‘conocermemas.com’ does not match target host name ‘188.226.194.196’

So we know your internal configuration works and you don’t have a certificate error -> the new certificate should work.

So it’s only a firewall problem. Or a wrong .htaccess, failban or another blocking tool.

2 Likes

I don’t understand how it can be a firewall problem if I haven’t touched anything on the firewall (iptables). And DigitalOcean’s cloud firewall is unsettled.

Is this normal?

2 certificates for the same domain?

https://crt.sh/?q=www.studiosh2o.com

It’s your configuration, so you have to fix it.

That’s a pre- and a leaf certificate with the same serial number, crt.sh shows boths. Normal.
“check your website” removes the duplicate, so only one certificate is shown.


PS: nginx -T

So that’s my configuration.

I go to sleep and everything works fine.

I wake up and I have the problem since 4 A.M.

Who has touched the configuration from the time I go to sleep until I get up if only I agree?

I executed nginx -T

No change.

First step: Ask your hoster.

@JuergenAuer is asking to see the output of nginx -T so he can help you.

How can I view studiosh2o.com from my PC wired to the router.

And I can’t see the page if I access it from my mobile phone with data (without wifi)?

@studios

So you can see with your cell phone that your site is not accessable from the internet. Only you can see the site from INSIDE your network.
Please consider the fact that your firewall is not the only firewall affecting your website.
You may not have “changed anything”… But your hosting provider (or ISP) MAY have noticed recent traffic on port 443 to your IP address and blocked it.
If you ask them for support that you pay for you will know the answer.

Help us help you. Make the call.
Rip

Oops almost didn’t think of it.
Between your nginx logs and your iptables logs you should be able to put to rest
some of these concerns.

Make sure your IPTABLES is set to VERBOSE logging.
do the ssllabs test again. (on SSLLABS site, refresh the cache so ssllabs reruns a new test)

Then if your logs (nginx and iptables) show port 443 connection attempts being blocked you can address it internally.
If your logs show NO blocking on connections to port 443 it is highly likely your ISP or hoster will bear responsibility.

Hope this helps
Rip