aptalca

Let me clarify, you do not need to enable listening on port 80 in the "nginx site config", because letsencrypt validation does not use the nginx webserver. During validation, it first stops nginx, and then puts up its own webserver (bootstrap based) that is listening on port 80. After validation, nginx is started back up. So you do need port 80 forwarding on the router to the container and the container needs the mapping for port 80, but nginx does not need to listen on 80 through its site config. In the past, validation was being done through port 443, so you didn't even need to forward port 80 on the router. But since letsencrypt disabled that, validation has to be done through 80.

We have a new test version of the letsencrypt image with dns validation support. I tested it with cloudflare and it works well. I need volunteers to test it with other dns providers. If you are using the following dns providers and are willing to test, please pm me and I'll send instructions. Cloudflare (already tested) Cloudxns Digitalocean Dnsimple Dnsmadeeasy Google Luadns Nsone rfc2136 Route53 (aws)

The webgui allows you to manage all the vpn users and their certs. Someone with access to the webgui can create a user for themselves and download its cert so they can connect to your vpn and bam they are in your network.

Are you accessing the site at https://xxxx.duckdns.org?

Read my reply in the letsencrypt thread. I strongly recommend against making this webgui accessible over wan

I would strongly recommend against that for security reasons. VPN is considered pretty secure because it uses a certificate to authenticate. The web gui on the other hand only uses a password that can be brute forced. Once hacked, they can create their own cert through the web gui to get into your LAN Once you create the user cert, you shouldn't need to access the web gui remotely. If you really need to, you can vpn in, and then access the gui

Thanks for the heads up. Http/dns was a typo. With regards to the options, the certbot options make no sense because automation is always an afterthought for them. And their documentation is sub par. I added the noeffemail one (must be new, first I'm seeing it) as well as the ip logging one. But nowhere does it say you can't use non interactive with manual. Oh well. I removed it anyway. In order to test, you can clone the github repo, enter the folder, and do "git checkout dns" and then build a docker image locally with "docker build -t lednstest ." (don't forget the period at the end) it will build a local image with the name "lednstest" Then you can create a new container with the same options, but instead of using "linuxserver/letsencrypt" at the end, use "lednstest" (or in the unraid gui, change the image repo in advanced settings) Make sure you set the variable DNSVAL to true, and have your authenticator.sh and cleanup.sh scripts in the config folder. Let me know if that's clear

Check if there's anything listening on the host

Invalid response could mean letsencrypt is reaching a different web server through port 80. Is your router interface available on port 80 from the wan? Try going to your ip at port 80 from the outside and see what you get

It seems you changed the container port of nextcloud to 444, that should be 443 Can you access it directly? I bet not

You're good until your cert is about to expire, or until you make changes to the subdomains, whichever comes first

Read the last few pages again because you set the HTTPVAL to false

Would you be willing to test that branch? It is currently untested. I can provide instructions, let me know

acme.sh is a 3rd party client. Its dev created a bunch of dns update scripts himself. We don't use that. We use the official letsencrypt client, certbot. With that, you have to supply your own authenticator.sh and cleanup.sh scripts for your dns provider. Here's a dns validation mock up where it requires you to supply your own script: https://github.com/linuxserver/docker-letsencrypt/tree/dns We haven't yet decided whether we will publish it or not

All dns provides use different apis. The users would need custom scripts specific to each dns provider. It's not as simple as setting your variables. You need to have a custom script for your provider. We can't write scripts for all the hundreds of different dns provider apis.

If port 8881 on your router is forwarded to the same port 80 in the container, nginx won't know the difference. Map a separate port into the container for that and create a new server block listening at that port EDIT: On second read, if it's a different container, you shouldn't have that problem (I think). I do that too with emby, but it uses https. Perhaps browser cache from before causing issues?

It seems your redirect of http to https is not working, but you have hsts working. Check your nginx config. Google has plenty of guides for that

Read through the last few pages

If you're not using unraid 6.4.0, there won't be revalidation until your certs expire. But as chbmb mentioned, new unraid pushes template updates, including newly added variables, which I wasn't aware of. That caused revalidation. Or, you can switch the image to nginx instead of letsencrypt and it will start without the letsencrypt bits.

Your port forwarding is wrong. You are forwarding 81 to 80, you should be forwarding 80 to 81

Wow that's a pretty dick move. Now their name makes more sense

Are you sure it blocks it or does the modem's webpage run on port 80? If the latter you might be able to change it to another port

Check your settings, you have two HTTPVAL directives, second one is setting it to false

I will only post this once. Feel free to refer folks to this post. A few points of clarification: The last update of this image didn't break things. Letsencrypt abruptly disabled the authentication method previously used by this image (tls over port 443) due to a security vulnerability. It is unclear whether they will ever re-enable it again. So we added the option of validating over port 80, via setting the HTTPVAL variable to true (similar to how PUID is set to 99). But you have to make sure port 80 is forwarded to the container from your router. Keep in mind that unraid gui runs on port 80, so you should map port 80 on your router to any other port, ie. 85. Then in the container settings, map port 85 to port 80. Unraid template has been updated to include this new variable setting, and I think the brand new unraid stable as well as the previous betas will automatically add that variable to your settings (not 100% sure because I'm still on 6.3.5). Either way, check your settings. If your isp blocks port 80, there's nothing we can do as it is the only port letsencrypt will validate through at this point. Someone mentioned dns validation. It's not gonna happen as it is. It requires a script to change dns settings on your dns provider. Since all the dns providers have different api's for this process, we cannot automate it for you, therefore we will not add dns validation (unless there is a standardized way to update dns entries in the future but I wouldn't hold my breath). You do not need to make changes to your nginx site config and you do not need to enable listening on port 80. Validation is done through a separate web server temporarily put up during validation and is not affected by your nginx config. And one last thing, the error message about the directory not existing is harmless, it just means that you didn't have a letsencrypt cert the last time the container was started, probably because the validation had failed.

Extra parameter makes things a little more complicated because it is hidden in advanced view and such. Just add a new environment variable in the gui where the key is HTTPVAL and the value is true similar to how there is already a variable for PUID and 99