Account registered.
Requesting a certificate for familjenisback.duckdns.org
Performing the following challenges:
http-01 challenge for familjenisback.duckdns.org
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Challenge failed for domain familjenisback.duckdns.org
http-01 challenge for familjenisback.duckdns.org
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: familjenisback.duckdns.org
Type: dns
Detail: DNS problem: SERVFAIL looking up A for familjenisback.duckdns.org - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for familjenisback.duckdns.org - the domain's nameservers may be malfunctioning
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
so its the dns server that is struggling now? is everything on my side good enough to get a certificate
Hard to tell, but I'm leaning to "no". Because your /etc/nginx/sites-enabled/default, which is still present I presume, should contain the reverse proxy directives from nginx to Immich. But when I go to your hostname, I only see the nginx default welcome page, not Immich. So for some reason, your nginx is still not correctly configured. That's why I asked for the sudo nginx -T output again.
Also, I see now that the default configuration file from earlier contained the port 443 HTTPS server section that wouldn't work, so I guess the default file requires/required some modification too.
Can you please show me all the active nginx configuration files?
It is best not to guess. The below command will show the actual nginx config. Please post output of this. Upper case T is essential
sudo nginx -T
Or upload the config.txt resulting from this. Run from your home directory or some other temp directory so this txt file not placed in any active nginx directory
That file can't be actually active as it's referring to the not-yet existing certificates which gave you trouble to begin with.
You should make sure the first half of that default file (with the listen 80; part) needs to be active. It's probably a good idea to replace the server block from nginx.conf with the port 80 server block from default, because it seems the default file isn't being loaded at all.
Probably. But OP had some issues with non-existing certs attempted to be loaded in their chat with ChatGPT, so somehow there was some kind of include in the past.. Not sure what's going on now.
sudo certbot certonly --dry-run --webroot -w /var/www/html -d familjenisback.duckdns.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for familjenisback.duckdns.org
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: familjenisback.duckdns.org
Type: dns
Detail: DNS problem: server failure at resolver looking up A for familjenisback.duckdns.org; no valid AAAA records found for familjenisback.duckdns.org
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
harrykotten@pi:~ $
That's still the DNS problem with DuckDNS. Please try again until you either get a success or something else than "DNS problem". Note that with the staging environment (by using --dry-run), you can test very often due to way less strict rate limits (for most testing practically non-existent).
Also note that this certonly --dry-run test is probably not the best command for a production cert by simply removing the --dry-run. I'd recommend for a production cert the command from earlier with -a webroot -i nginx.
Well, you can test that latter command too with --staging, but it behaves differently than the certonly subcommand with --dry-run. With --dry-run, Certbot really gets into testing mode, not storing the test cert anywhere for example. However, with -i nginx and --staging, Certbot will run just as with the production environment, including with the installation of the issued cert, but then simply uses the staging environment. So you'd end up with a staging cert installed into nginx, which would need to be replaced by valid a production cert.
Does using just --staging invalidate cached authorizations? I have always assumed it did not but I never tested that.
Given their somewhat unusual nginx config, using the --nginx installer isn't what I'd recommend. Certainly opinions can vary on this That isn't why I suggested that certonly --dry-run though. I really wanted to see just that test.
@harrykotten Don't let these comments detract from the main problem which is the duckdns DNS system.