Help with HTTPS not working (nginx, deb 11, self-hosted)

Help
1

Hello everyone, I managed to use my desktop pc as a web server, but after I try to use

sudo certbot --nginx

to enable https my website just stops working.
I had the same issue with arch linux and I switched to debian to check if maybe it was an issue with arch.
My domain is alessandroveller.xyz (shame I have to self-dox but I really want to make this work :p).
I tried to chmod 777 every file in /etc/letsencrypt to see if it there was an issue with file permissions and I've enabled ports 80 and 443 both with ufw and on my home router.
What am I doing wrong? Thanks in advance for your help & time

2

Hi @AdamJensen,

It's hard to be sure, but I think your ISP may be blocking the incoming connections with its own firewall.

The reason I think this is that I can ping your server, but when I try to make a TCP connection, I get an ICMP error back saying "Host unreachable". Yet this depends on the TCP port I try to connect to: if I try to connect to port 80 or 443, I get that, but if I try to connect to some other port, I get a different ICMP error, "Administratively prohibited".

This variety of different responses depending on higher-level protocol is really reminiscent of the behavior of a firewall, even if it's not your own firewall.

1 Like
3

It's probably my fault, I turned the pc off when I went to sleep to save on the electricity bill. I'll keep it on semi-permanently from now on. Sorry for being dumb

4

It seems something on your network is blocking port 443. Please see and appriciate the following traceroute commands:

osiris@erazer ~ $ sudo traceroute -T -p 80 alessandroveller.xyz
traceroute to alessandroveller.xyz (2.236.84.15), 30 hops max, 60 byte packets
(...)
11  193.134.95.223 (193.134.95.223)  46.137 ms  35.651 ms  36.824 ms
12  * * *
13  * * *
14  2.236.84.15 (2.236.84.15)  43.086 ms  42.075 ms  43.059 ms
15  2.236.84.15 (2.236.84.15)  54.531 ms  44.057 ms  44.917 ms
osiris@erazer ~ $ sudo traceroute -T -p 443 alessandroveller.xyz
traceroute to alessandroveller.xyz (2.236.84.15), 30 hops max, 60 byte packets
(...)
11  193.134.95.223 (193.134.95.223)  46.690 ms  36.986 ms  36.933 ms
12  * * *
13  * * *
14  2.236.84.15 (2.236.84.15)  42.648 ms  42.633 ms  42.619 ms
15  2.236.84.15 (2.236.84.15)  3104.776 ms !H  3104.763 ms !H  3104.750 ms !H
osiris@erazer ~ $

(You can ignore steps 11 through 13.)

The first one is for TCP port 80. Notice that steps 14 and 15 are the same IP address: your IP address. This makes me believe there is a NAT device in front of your server, maybe your router?

You can also see the port 80 traceroute is successful: just regular ping timings as output on step 15.

Now, the second part is for port 443. It's almost the same with the two steps 14 and 15 for your home IP address again. Step 14 is probably your NAT router replying again. BUT: step 15 gives trouble: you can see the !H errors. That's an active ICMP reply with "Host unreachable", perhaps the same @schoen mentioned above.

As the "host unreachable" error is coming from the second step of your home IP address, this makes me believe that it can be either two things:

  • Your own server has a firewall set up blocking port 443;
  • Or your home NAT router doesn't have a port forward for port 443 to your server set up.

I'm not so sure about the port forward, as it's step 15 failing while I'd expect step 14 already failing without a port map, but it's worth looking into it nonetheless.

5

I don't think that I have an issue with my server, since I already allowed ports 80 and 443 with iptables and ufw, so I assume it's a router issue.

image
image1463×70 8.77 KB

this is what I see in my router config page and the "0 in funzione" is referring to automatic port forwarding.

6

Oh God, it just came to me that it could be an issue with my ssh port, which is a number that's reeeeeally close to the https port. Could that be the issue?

7

Probably not. Portmaps look good to me.

Another strange thing I just noticed an missed before: look at the actual timings of those ICMP replies: 3 seconds!

Which device is returning those ICMP error packets? :thinking: So if it isn't your NAT router, it must be your server.. Is nginx configured to listen on port 443?

1 Like
8

My server config is

server{
    server_name alessandroveller.xyz;
    root /var/www/alessandroveller;
    index index index.html test main;
    location / {
        try_files $uri $uri/ =404;
    }




    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/alessandroveller.xyz/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/alessandroveller.xyz/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 = alessandroveller.xyz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name alessandroveller.xyz;
    listen 80;
    return 404; # managed by Certbot


}

and my nginx.conf is

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}


#mail {
#   # See sample authentication script at:
#   # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#   # auth_http localhost/auth.php;
#   # pop3_capabilities "TOP" "USER";
#   # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#   server {
#       listen     localhost:110;
#       protocol   pop3;
#       proxy      on;
#   }
#
#   server {
#       listen     localhost:143;
#       protocol   imap;
#       proxy      on;
#   }
#}
9

Doesn't look incorrect..

Can you try if you can access your own site from within your network? E.g., by running curl -LIv alessandroveller.xyz ?

10

I don't think I can

[alex@jonathan]~$ curl -LIv alessandroveller.xyz
*   Trying 2.236.84.15:80...
* Connected to alessandroveller.xyz (2.236.84.15) port 80 (#0)
> HEAD / HTTP/1.1
> Host: alessandroveller.xyz
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: nginx/1.18.0
Server: nginx/1.18.0
< Date: Sat, 02 Oct 2021 11:03:27 GMT
Date: Sat, 02 Oct 2021 11:03:27 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 169
Content-Length: 169
< Connection: keep-alive
Connection: keep-alive
< Location: https://alessandroveller.xyz/
Location: https://alessandroveller.xyz/

<
* Connection #0 to host alessandroveller.xyz left intact
* Issue another request to this URL: 'https://alessandroveller.xyz/'
*   Trying 2.236.84.15:443...
* connect to 2.236.84.15 port 443 failed: No route to host
* Failed to connect to alessandroveller.xyz port 443 after 9277 ms: No route to host
* Closing connection 1
curl: (7) Failed to connect to alessandroveller.xyz port 443 after 9277 ms: No route to host

This is so annoying :c

11

I assume that's from a different host within your own network? What if you put the local IP address of the server in the /etc/hosts file of your client? I.e.:

192.168.0.1 alessandroveller.xyz

Where you'd need to substitute the IP address 192.168.0.1 of course with the actual local IP address of your server.

If you were running curl from the server itself please try localhost as the IP address for your hostname on the /etc/hosts file on the server itself:

127.0.0.1 alessandroveller.xyz

And try curl again.

2 Likes
12

I'm assuming that it worked this time, I put the local ip of my server on my laptop's /etc/hosts:

[alex@jonathan]~$ curl -LIv alessandroveller.xyz
*   Trying 192.168.178.50:80...
* Connected to alessandroveller.xyz (192.168.178.50) port 80 (#0)
> HEAD / HTTP/1.1
> Host: alessandroveller.xyz
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: nginx/1.18.0
Server: nginx/1.18.0
< Date: Sat, 02 Oct 2021 21:21:43 GMT
Date: Sat, 02 Oct 2021 21:21:43 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 169
Content-Length: 169
< Connection: keep-alive
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.18.0
Server: nginx/1.18.0
< Date: Sat, 02 Oct 2021 21:21:46 GMT
Date: Sat, 02 Oct 2021 21:21:46 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 653
Content-Length: 653
< Last-Modified: Tue, 28 Sep 2021 15:39:28 GMT
Last-Modified: Tue, 28 Sep 2021 15:39:28 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "61533730-28d"
ETag: "61533730-28d"
< Accept-Ranges: bytes
Accept-Ranges: bytes

<
* Connection #1 to host alessandroveller.xyz left intact
13

Could it maybe have something to do with my server's /etc/hosts? It was auto-configured by debian so it only has the usual 127.0.0.1 localhost stuff

1 Like
14

Hm, a little bit strange output of curl if you'd ask me. I do see HTTP/1.1 301 moved permanently first and then HTTP/1.1 200 OK, but I didn't see the actual "Location" header or the connecting to port 443 part? Is this output complete?

I doubt it, hosts deals with hostnames. /etc/hosts just resolves hostnames to IP addresses without using DNS.

That said: did you modify something so port 80 now isn't working either? I know get the same traceroute and "no route to host" for port 80 and port 443..

1 Like
15

The ping times seem really high.
Is the server overloaded?
How does the CPU and memory look?

1 Like
16

Those 3 seconds ping times are only there when the port is blocked with and result is "no route to host". Back when port 80 was still open, the ping times for that port were normal.

I'm thinking timeouts for some downstream connection. Something in the line of: "router sends packets through to a secondary device on the network and waits for a response. It doesn't get a response within 3 seconds, so it returns "no route to host"."

I guess the device has been turned of at the moment, maybe port 80 will be up again once the device is powered on.

2 Likes
17

The output is complete and my power shut off while I was sleeping so it's probably why port 80 was dead as well.
I'm so sorry that this keeps happening and I'm genuinely grateful that you're still trying to help me

1 Like
18

So yes, port 80 is back up again, but port 443 still isn't.. My best theory is that packets for port 443 are blocked by your server somehow.

1 Like
19

What can I check? (and how?)

20

Follow the money packets.
Internet > router [check router port forwards both 80 and 443 to the SAME internal IP]
router > server/PC [make sure the local firewall allows 80 and 443 in]
server/PC > web server [make sure the web server is listening on ports 80 and 443(SSL on)]