I’m trying to setup access to my home assistant to the internet via ssl on a duckdns address, so that the http challenge succeed.
Trying to understand how this addon it’s working.
From what I understand till now, it seems that the addon usese an sqllite db to store settings (/usr/share/hassio/addon_configs/a0d7b954_nginxproxymanager/database.sqlite).
Nginx, I suppose, takes settings from conf files stored in /usr/share/hassio/addon_configs/a0d7b954_nginxproxymanager/nginx/proxy_host
The first setting for proxy host is called /usr/share/hassio/addon_configs/a0d7b954_nginxproxymanager/nginx/proxy_host/1.conf. Modifying this file seems not to update addon web interface. Anyway I try to modify it and it seems that nginx read it correctly. I set up to serve files from /var/www/html with this configuration
server {
listen 80;
# server_name myname.duckdns.org;
location / {
root /var/www/html;
index index.html index.htm;
allow all;
}
}
The NGINX Proxy Manager addon automatically renews DuckDNS certificates using Let’s Encrypt configured through the UI. It’s not clear to me why you’re manipulating files.
Finally succeded using dns validation on my namecheap server.
It’s really straightforward, just insert the correct login credential in the nginx proxy manager.
Go to “edit proxy host” of your server and insert namecheap’s username and key.
Note: not necessary as the addon do everything for you, but…if you insert the TXT record directly on namecheap web administration, beware that you didn’t have to insert the domain name i.e.: for mySubDomain.myDomain.org the txt name must be _acme-challenge.mySubDomain.
I didn’t realize why the http challenge didn’t work for my server (myDomain.duckdna.org)
It seems that the ACME HTML handshake on port 80 isn’t activating automatically. I’ve been trying to understand how it works and have started troubleshooting. Here’s my last attempt:
[1/9/2025] [9:28:07 AM] [Nginx ] › ⬤ debug Deleting file: /config/nginx/temp/letsencrypt_1.conf
[1/9/2025] [9:28:07 AM] [Nginx ] › ℹ info Reloading Nginx
[1/9/2025] [9:28:07 AM] [Express ] › ⚠ warning Command failed: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-1" --agree-tos --authenticator webroot --email "[email protected]" --preferred-challenges "dns,http" --domains "myServer.duckdns.org"
Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details.
It seems the problem is correlated to the Docker image where the addon resides. There's no `/etc/letsencrypt.ini` on my Debian system. Instead, I found the file at `/var/lib/docker/overlay2/5612edc8e71dab698026859b5c45ea836df8e0badcf98a6009c0f8e30d8edf31/diff/etc/letsencrypt.ini`.
Since I don’t know much about Docker, I’m wondering if the addon can see the correct path to /etc/letsencrypt.ini inside the image?
I got into bash of the docker addon image and all dirs are in place using the instruction
When activating the registration of certificate from addon web interface it fails to contact the ACME client on my HA server’s port 80.
I can access the root of addon site http://my_dns_name.duckdns.org on port 80 (i modified the index.html and I see the modified version contacting the site with my dns name).
During certificate creation I repeatedly CURLed the site at address http://my_dns_name.duckdns.org/.well-known/acme-challenge/2sUwmBHsyIgqS6x_O126OT1ZCclTsIepB3-lRUS1VJo and also (from container bash) http://localhost/.well-known/acme-challenge/2sUwmBHsyIgqS6x_O126OT1ZCclTsIepB3-lRUS1V but it always gave me 404.
So I tried to manually create /.well-known/acme-challenge/2sUwmBHsyIgqS6x_O126OT1ZCclTsIepB3-lRUS1VJo but it didn’t get donwloaded.
So I tried to manually create (without dot in .well-known) /well-known/acme-challenge/2sUwmBHsyIgqS6x_O126OT1ZCclTsIepB3-lRUS1VJo and it worked.
Could it be the same problem of “.well-known” dir not reachable to confirm the certificate?
I do not think the port 80 (HTTP) connection is going to the NginX addon, but instead directly to the Let’s encrypt or DuckDNS addon, so you should just portforward port 80 to the HA IP address.
Default configuration uses port 80 for http, 443 https and 81 for addon web interface.
Anyway it’s reachable from internet with my dns address as I mention on my troubleshootings.
In my case it didn’t happen. Now I’m trying to activate via DNS handshake (I’m waiting for TxT record propagation).
If it didn’ work, I’ll try again to understand what’s the problem with the ACME client
I discovered that the “/.well-known” directory of web server was pointing to /var/www/html/.well-known
but “/.well-known/acme-challenge” was pointing to /config/letsencrypt-acme-challenge/.well-known/acme-challenge
So I’m able to set the correct file with correct content for challenge.
the response was ok.
After pressing a key, so that certbot could verify it, I got a timeout error.
It seems that this resource isn’t reachable from the certbot server!!!
Now that I’ve understood how it’s working, I saw that also the ACME client it’s working fine, automatically creating the files to respond to the challenge. The problem lies in the fact that the request to my webserver from ACME server is getting a timeout.
