Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version): OpenMediaVault 5
The operating system my web server runs on is (include version): Debian 9
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.31.0
According to network tests, your port 443 and 80 are both filtered. This means there’s either a firewall blocking such ports, a router that didn’t forward correctly or your ISP blocked it.
Please check your firewall and port forwarding first.
My goal here is to access files on my server remotely.
So I did setup nexcloud and it is up and running.
From my local LAN I can start through a web browser the Nexcloud UI , I can see files , etc.
Server IP , public IP , all checked and ok.
Nextcloud should work remotely through duckdns DDNS / letsencrypt.
But because letsencrypt doent work , my files are not visible outside my local LAN.
Let’s Encrypt is trying to check via HTTP on port 80. That doesn’t work from outside your LAN, and it needs to work properly before Let’s Encrypt can complete this test.
That did make a difference, from what I can see. You currently have a redirection rule that redirects everything from http://rsvcloud.duckdns.org/ to the corresponding URL on https://rsvcloud.duckdns.org/, which means that the HTTPS service would need to be available too in order to complete the validation process. Or you would need to make an exception so that /.well-known/acme-challenge is excluded from this redirection rule.