SteveLTN
use https-portal offline?
Hi Steve, I'm currently trying to get a nr of docker containers running over https and got nicely signed certificates for the next 90 days and subdomains are mostly directed to the correct containers. I've setup my subdomains, domain forwarding locally on my router and all works right till the point that I want to bring all in 'offline-mode'. Perhaps my usecase is not what https-portal is intended for but what I would like to do is close port 80 and 433 on my router again so that I can only access my applications from my local LAN. Should this work with https-portal? Or should I keep looking for a different way to achieve this with a different redirecting service?
the errors I eventually got were:
host not found in upstream "[containername]" in /etc/nginx/conf.d/pads.domain.org.ssl.conf
which results in constant reboots of the https-portal container
Closing port 80 and 443 after getting the certificate should work. HTTPS-PORTAL should be able to keep running, until when it wants to renew the certificate (usually 1 week before expiry).
Personally I wouldn't use HTTPS-PORTAL in your case because you need to remember to open the ports for renewal. If it doesn't bother you, you might just go to https://www.sslforfree.com/, and manually download the certificates every 3 months.
Opening two ports on my router for a few minutes is less work than generating/downloading and distributing new keys, I think... but I appreciate the suggestion! It's running now for half a day with the ports closed but when I was testing and trying to get my unifi docker working under https-portal the portal ended in a restart loop leaving me with containers I could not access any more.
Not sure if it is because my unifi controller is adding some extra values in my dns forwarder of my router, I'm not a DNS expert, or because the controller was initially running in net_mode: host but when removing the host mode and only exposing the ports the unifi controller requires I couldn't access the controller any more. I'll keep testing to see if I can get it to work or if I need to try a different reverse proxy for my specific usecase.
Do you see any logs when it get restarted? Is it possible that the device doesn't have enough RAM? Also, I'm not sure Unifi supports x86 binary.
I haven't tried messing with the settings yet, to get unifi working. Will try it soon again. Right now, https portal has been running healthy for 3 days
https-portal still running healthy. Trying now to get unifi controller working but the docs mention I need *.pem files and https-portal is generating .cert files. I'm a complete n00b regarding certs, any thoughts?
Hi, it's just naming. Usually they mean the same thing. Rename the files and you'll be fine. On 12 Nov 2019, 11:07 AM +0100, René Sluiter [email protected], wrote:
https-portal still running healthy. Trying now to get unifi controller working but the docs mention I need *.pem files and https-portal is generating .cert files. I'm a complete n00b regarding certs, any thoughts? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
cool! thanks for the quick response.
One step closer: in docker-compose I added the cert folder mapping and three new environment variables:
- CERTNAME=signed.crt
- CERT_PRIVATE_NAME=domain.key
- CERT_IS_CHAIN=true
Certificate is valid now if I go to unif.mydomain.com:8443, but the unifi container still needs to run in host mode. If I remove that than I can't access the unifi controller and get the error:
Bad Request
This combination of host and port requires TLS.
https-portal is setup for unifi:
environment:
STAGE: 'production'
DOMAINS: 'unifi.mydomain.com -> http://unifi:8443'
ok, removed the network_mode host but still need to map the port 8443 for it to work. Almost there.