January 15, 20188 yr 14 minutes ago, Living Legend said: Figured out that my redirect of the unRAID HTTPS port to 445 created some unknown conflict. 442 worked. 442 worked, but no external access. I imagine this is a port forwarding issue. I thought this looked right, but apparently something is still wrong. I'll keep reading... EDIT: Restarted the docker one more time. Now it's working. Go figure. Edited January 15, 20188 yr by Living Legend
January 15, 20188 yr 47 minutes ago, CorneliousJD said: EDIT: Thanks I'll look into the nginx redirect part, and see if I can find a way to disable HSTS as well due to the below issue I had just posted. Unless someone knows a quick way to disable HSTS? Another, separate issue - I use my www.mydomain.com as kind of a shortcut page to other services, e.g. a shortcut on there links to my UniFi setup, which runs HTTPS on a different port than 443, and obviously doesn't use the same certificate. When I try to browse to that site I get Because this site uses HTTP Strict Transport Security, you can’t continue to this site at this time. That's in IE, and in Chrome it shows You cannot visit mydomain.com right now because the website uses HSTS. So I made progress on this - I got HSTS disabled - that worked okay. And I got HTTP to HTTPS redirect working, but that caused another problem. I have links on that site to http://mydomain.com:8881 etc that do not use HTTPS because it is not supported or offered. To try and get around this I tried to set a location on my redirect but that doesn't seem to be working to let it through on http:// only, it still tries to force an HTTPS redirect. My default site conf looks like this at the top server { listen 80; server_name _; location = / { return https://$host$request_uri; } }
January 15, 20188 yr 8 hours ago, CorneliousJD said: So I made progress on this - I got HSTS disabled - that worked okay. And I got HTTP to HTTPS redirect working, but that caused another problem. I have links on that site to http://mydomain.com:8881 etc that do not use HTTPS because it is not supported or offered. To try and get around this I tried to set a location on my redirect but that doesn't seem to be working to let it through on http:// only, it still tries to force an HTTPS redirect. My default site conf looks like this at the top server { listen 80; server_name _; location = / { return https://$host$request_uri; } } 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? Edited January 15, 20188 yr by aptalca
January 15, 20188 yr On 1/13/2018 at 3:45 PM, Taddeusz said: I already did just to make sure things haven't changed but Cox Cable blocks port 80. Verified as well. Let's Encrypt needs to allow other ports than 80, this is just silly. LSIO Nginx container will have to work until something changes. If I could get another ISP that offered 300mb/s connections where I live I would be all over it.
January 15, 20188 yr 20 hours ago, jonathanm said: What error shows in the docker log? I followed up with the logs. Any other ideas by chance? Thanks in advance.
January 15, 20188 yr 11 minutes ago, irandumi said: I followed up with the logs. Any other ideas by chance? Thanks in advance. I assumed you saw the other responses in this thread. Cox cable blocks port 80, no way around that.
January 15, 20188 yr 42 minutes ago, jonathanm said: I assumed you saw the other responses in this thread. Cox cable blocks port 80, no way around that. ooooooooh. Thanks for the follow-up!
January 15, 20188 yr hey guys, woke up this morning to a couple errors in letsencrypt out of no where, haven't changed the setting since i got it working months ago so i really dont know how to fix it Here's the log; Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... using keys found in /config/keys [cont-init.d] 30-keygen: exited 0. [cont-init.d] 50-config: executing... 2048 bit DH parameters present SUBDOMAINS entered, processing Sub-domains processed are: -d akrapps.akrapps.duckdns.org E-mail address entered: [email protected] Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ... Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate. certbot: error: argument --cert-path: No such file or directory Generating new certificate Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. IMPORTANT NOTES: - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container screenshot of letsencrypt settings i made sure all the duckdnsdns settings are good reinstalled both letsencrypt and ducksdns, and made sure the ports (81, 443) are still forwarded, but no use, its been working great for the past 4+ months so idk honestly.
January 15, 20188 yr 6 minutes ago, AKR said: hey guys, woke up this morning to a couple errors in letsencrypt out of no where, haven't changed the setting since i got it working months ago so i really dont know how to fix it Here's the log; Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... using keys found in /config/keys [cont-init.d] 30-keygen: exited 0. [cont-init.d] 50-config: executing... 2048 bit DH parameters present SUBDOMAINS entered, processing Sub-domains processed are: -d akrapps.akrapps.duckdns.org E-mail address entered: [email protected] Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ... Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate. certbot: error: argument --cert-path: No such file or directory Generating new certificate Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. IMPORTANT NOTES: - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container screenshot of letsencrypt settings i made sure all the duckdnsdns settings are good reinstalled both letsencrypt and ducksdns, and made sure the ports (81, 443) are still forwarded, but no use, its been working great for the past 4+ months so idk honestly. Might be an idea to look at the last few pages for a solution.
January 15, 20188 yr AKR- with the new 6.4 release, Unraid’s GUI is utilizing 443. You will need to change that to 442 or something similar and forward the ports as needed.
January 15, 20188 yr So I had problems starting the docker after updating and I changed the unraid port to 442 and the dockers seems to work again. Is there anything else I should do?
January 16, 20188 yr 12 hours ago, aptalca said: 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? Thanks for the second read on that - I had cleared cache a few times via automated tools but that didn't work... tried on a laptop that hadn't visited the site before at all and everything was good, so was totally a cache issue. doh. I cleared manually on my main desktop and everything was fine. Time to stop trusting tools to do things for me. Thanks for everything, all running how I want it to now with HTTPS from Let's Encrypt! Awesome job LSIO Team!
January 16, 20188 yr I am having the same issue with @AKR I am still running on Unraid 6.3.4 still. I switched the http port on the docker settings to 442 as suggested and port forwarded 442 to 443. I don't know if I am doing it right. Edited January 16, 20188 yr by Bisu
January 16, 20188 yr 5 minutes ago, Bisu said: I am having the same issue with @AKR I am still running on Unraid 6.3.4 still. you need to look back the last couple of pages, it is all covered there. If it still doesnt work after you have read and tried the steps post images showing settings and docker run command.
January 16, 20188 yr 5 hours ago, Bisu said: Edited 4 hours ago by Bisu This looks like it might be backwards, but hard to tell with just this little snippet. Try switching original and forward-to.
January 16, 20188 yr 18 hours ago, fc0712 said: So I had problems starting the docker after updating and I changed the unraid port to 442 and the dockers seems to work again. Is there anything else I should do? I did that too, and I cannot see why that would not be a good solution. So stick to it until you encounter a problem or someone else tells us why this would not be a good solution. Edited January 16, 20188 yr by truetype
January 16, 20188 yr 6 hours ago, jonathanm said: This looks like it might be backwards, but hard to tell with just this little snippet. Try switching original and forward-to. Hello, thanks for the response. I switched it around and I am still having the same error. Edit: I was able to resolve this issue. I recommend anyone who is having the same issue as this to start here - Edited January 16, 20188 yr by Bisu
January 16, 20188 yr On 1/13/2018 at 12:57 AM, matthope said: In my case, my internet provider block the port 80 so the HTTPVAL fix wont work. Since TLS-SNI challenge is deactivated and I can't use HTTP challenge, I'm obligated to use the DNS-01 challenge. I've found a way to use it with this docker and cloudflare. You will need those 2 scripts ( here ) and you will need to modify the script /etc/cont-init/50-config inside the docker. docker exec -it [DOCKERNAME] /bin/bash vi /etc/cont-init.d/50-config In the file comment this line : certbot certonly --non-interactive --renew-by-default --standalone --preferred-challenges $PREFCHAL --rsa-key-size 4096 $EMAILPARAM --agree-tos $URLS And add this one : certbot certonly --agree-tos --manual --manual-public-ip-logging-ok --preferred-challenges=dns --manual-auth-hook /app/authenticator.sh --manual-cleanup-hook /app/cleanup.sh --rsa-key-size 4096 $EMAILPARAM --no-eff-email $URLS However, this is a one time fix since any modification to the docker is reverted when restarted. @aptalca It would be nice if the DNS-01 challenge could be added definitively to this docker. DNS-01 challenge needs to be added to this docker per this update: https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
January 16, 20188 yr 7 minutes ago, surfshack66 said: DNS-01 challenge needs to be added to this docker per this update: https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 Aptalca adressed this in his post and said it's not happening. I've reverted to the LSIO nginx container and used a script for DNS-01 verification. https://github.com/Neilpang/acme.sh
January 16, 20188 yr 19 minutes ago, surfshack66 said: DNS-01 challenge needs to be added to this docker per this update: https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 8 minutes ago, BrandonG777 said: Aptalca adressed this in his post and said it's not happening. I've reverted to the LSIO nginx container and used a script for DNS-01 verification. https://github.com/Neilpang/acme.sh It's been discussed and given the difficulties people have been having with http_val and the fact that dns auth would require a lot more end user configuration and understanding, it's not a viable option.....
January 16, 20188 yr 1 minute ago, CHBMB said: It's been discussed and given the difficulties people have been having with http_val and the fact that dns auth would require a lot more end user configuration and understanding, it's not a viable option..... Seems like the stupid simple fix here is for Let's Encrypt to allow http verfication on ports other than 80 but maybe I'm missing something.
January 16, 20188 yr 11 minutes ago, BrandonG777 said: Aptalca adressed this in his post and said it's not happening. I've reverted to the LSIO nginx container and used a script for DNS-01 verification. https://github.com/Neilpang/acme.sh Since this seems to be the new reality and my ISP blocks port 80 how do I go about implementing this script with unRAID and the regular nginx container?
January 16, 20188 yr Just now, BrandonG777 said: Seems like the stupid simple fix here is for Let's Encrypt to allow http verfication on ports other than 80 but maybe I'm missing something. Nope, you're right, it would be, but they don't To be fair, most people don't have an issue with port 80 and the vast majority of problems we've seen in the thread have been down to lack of understanding on port forwarding and docker. But I can understand how frustrating it must be for those of you with port 80 blocked.
January 16, 20188 yr 16 minutes ago, Taddeusz said: Since this seems to be the new reality and my ISP blocks port 80 how do I go about implementing this script with unRAID and the regular nginx container? The LE container is directly replaceable by the LSIO nginx container. Probably just need to comment out your cert paths in the nginx configuration and then it will start and you can shell into the container and use the script I linked to. Unfortunately I do not have the time right now to write up a good step by step guide. I really don't have the time to deal with this in general at the moment but being I left autoupdate enabled I pretty much brought this on myself and just have to deal with the fallout. EDIT: Something I probably should have mentioned, you will need DNS control of the domain in question. I use Google Domains, which allows Dynamic DNS updates within my own domain. Edited January 16, 20188 yr by BrandonG777
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.