-
Posts
3,064 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Everything posted by 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)
-
[Support] Linuxserver.io - OpenVPN AS
aptalca replied to linuxserver.io's topic in Docker Containers
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
-
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
-
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?
-
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.
-
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.