I believe my issue lies within my nginx server configuration. I believe i set up automatic redirect to HTTPS with a self-signed certificate, then set up the well-known location here. Just in case i also set-it up to work with http.
Is 220.127.116.11 the server's actual IP address? Yes
If you host it at home, did you enable port forwarding? also, yes
Did you check your firewalls? (OS, router, ISP, ...) the web server works (its just a reverse proxy wthat you can reach with subdomains
(Your config is a bit messy... but it doesn't matter, it should work) yeah, sorry a bit confusing since i copied from an online tutorial and played with it a bit to try to get it to work
You did mount the right volumes, right? (The docker-compose command is also messy: you can usually do docker-compose run servicename command ) i believe so. (and yes i'm also copying from a script i found for first time set-up with let's encrypt)
I'm not sure my automatic redirect works well either, it seems like it only sometimes works.
Well... I can't reach it. And neither can the validation bots.
And ok, I just realized what the problem is: you are only listening on port 443. You must listen on port 80 (forward it!) as well, to use http-01.
% nmap mazornas.net
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-02 21:41 CEST
Nmap scan report for mazornas.net (18.104.22.168)
Host is up (0.093s latency).
rDNS record for 22.214.171.124: 126.96.36.199.adsl.012.net.il
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE
443/tcp open https
1122/tcp open availant-mgr
Nmap done: 1 IP address (1 host up) scanned in 9.33 seconds
This doesn't make too much sense either. Using RSA4096 "because it's safer" without considering how much slower (A LOT) it is is not a good thing and the main advantage of it are bragging rights.
@mazora please use an ecdsa p-256 key if you want stronger encryption, or stick with RSA2048. If you want to go for overkill, p-384 is an option (but it will be slow. not as slow as RSA4096, tho, and with security equivalent to an rsa key three times as long.)
Type of generated private key. Only *ONE* per
invocation can be provided at this time. (default:
--elliptic-curve N The SECG elliptic curve name to use. Please see RFC
8446 for supported values. (default: secp256r1)
You should keep the default. The only other option is secp384r1, which is overkill.
Actually, there is. But it depends on which ciphers you enabled.
If you only have strong ciphers, turn it off.
For example, if you only have AES GCM and CHACHA20 (defaults for TLS 1.3 that also work for 1.2), turn it off: it will allow phones to use CHACHA20 while PCs will use AES GCM, every client will use the faster and more optimized cipher, instead of the same for everybody.
But, if you want to support clients with older ciphers... That depends on how old.
That assumes the clients have their cipher list preference in a proper order.
From what I've seen MS do with Windows, I'd say that is not the case.
I'd rather control that at the server than leave it to the clients.