My goal is to have Nginx return it’s example welcome page while using https.
I used certbot to create the certificates with the following command:
certbot --nginx -d api.example.com
In my /etc/nginx/conf.d/nginx-example-server.conf
I have the following block:
server {
listen 443 ssl;
server_name api.example.com
ssl_certificate /etc/letsencrypt/live/api.example.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
}
the include /etc/letsencrypt/options-ssl-nginx.conf;
includes the following:
ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers: "<Lots of cyphers>"
ufw status verbose
returns:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
443/tcp ALLOW IN Anywhere # Open all to access Nginx port 443
80/tcp ALLOW IN Anywhere # Open access Nginx port 80
22/tcp ALLOW IN Anywhere # Open access OpenSSH port 22
8000 DENY IN Anywhere
443/tcp (v6) ALLOW IN Anywhere (v6) # Open all to access Nginx port 443
80/tcp (v6) ALLOW IN Anywhere (v6) # Open access Nginx port 80
22/tcp (v6) ALLOW IN Anywhere (v6) # Open access OpenSSH port 22
8000 (v6) DENY IN Anywhere (v6)
If I visit https://api.example.com (not the real url, of course) it responds with ERR_ADDRESS_UNREACHABLE
.
/var/log/nginx/access.log
and /var/log/nginx/error.log
both don’t log anything concerning the ERR_ADDRESS_UNREACHABLE
.
I tried to find my ufw
log files, but there aren’t any. I tried to find them as described in here: https://serverfault.com/a/516840
I have looked all over for tips and followed a few tutorials. Everything results in the same response. I can succesfully reach the Nginx welcome page over http though.
Help is very welcome! Even if it’s only a better way to debug this thing.
2
Answers
This fixed it:
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT
As posted here: https://stackoverflow.com/a/50373181/6565435
Necrones are here.
If someone has the same issue, try to check your
ip route
.Maybe some interfaces "covers" necessary ip adresses. For example, it could be some docker-compose bridges (name of the interface will be like "br-…").
To check if it so, you can do next steps:
systemctl disable docker
– to disable docker service autostart.ip route
again. If some bridges do not appear there now, they were tied with docker service.Why?
Somethimes it happens when you did use docker-compose: it creates a lot of virtual net interfaces.