I have a reverse proxy(traefik) on my LAN to handle sub domain service routing. I want https but don’t want to have to install certs on all the clients using the services. I want the s but don’t want my services to be unavailable if my Internet goes down.
Then no, you won’t be able to access your service via https when your internet is down because it’s terminated at cloudlare’s server. You can still access your service directly without https, or with https but with a self-signed certificate.
Thanks for elaborating. Thats exactly my usecase. You can use lets encrypt certs with a dns challenge I believe. You wildcard a subdomain like *.abc.def.com
I believe you have to expose your ports once to get the cert and close them immediately. You set the domain to point to the public ip of your router, get the challenge done, close ports and the public domain goes nowhere.
Install the cert, point the local dns to your server ip, done.
I don’t know if cloudflare can do this, but I have a different DDNS + Let’s Encrypt setup and I configure my router to set the same local domain as the public domain (in openwrt it’s local server + local domain although I’m not aware of the distinction between the two). So when requests are sent over LAN (or over a VPN) the router points me to the LAN device directly, rather than needing to go through external DNS. HTTPS still works since to the client it’s the same domain as the certificate is linked to.
Hope that makes sense as I haven’t fully got my head around it. I just know it works (indeed I just disabled my internet to test, and the services are still accessible over HTTPS).
If your only goal is working https then as the other comment correctly suggests you can do DNS-01 authentication with Let’s Encrypt + Certbot + Some brand of dyndns
However the other comment is incorrect in stating that you need to expose a HTTP server. This method means you don’t need to expose anything. For instance if you do it with HA:
Certbot uses the API of your DDNS provider to authenticate the cert request by adding a txt record and then pulls the cert. No proxies no exposed servers and no fuss. Point the A record at your Rfc1918 IP.
You can then configure your DNS to keep serving cached responses. I think though that ssl will still be broken while your connection is down but you will be able to access your services.
Edit to add: I don’t understand why so many of the HTTPS tutorials are so complicated and so focused on adding a proxy into the mix even when remote access isn’t the target.
Cert bot is a shell script. It asks the Lets Encrypt api for a secret key. It adds the key as a txt record on a subdomain of the domain you want a certificate for. Let’s encrypt confirms the key is there and spits out a cert. You add the cert to whatever server it belongs to, or ideally Certbot does that for you. That’s it, working https. And all you have to expose is the rfc1918 address. This, to me at least, is preferable to proxies and exposed servers.
I have a reverse proxy(traefik) on my LAN to handle sub domain service routing. I want https but don’t want to have to install certs on all the clients using the services. I want the s but don’t want my services to be unavailable if my Internet goes down.
You only need a letsencrypt cert on the reverse proxy, the services themselves don’t need them.
Then no, you won’t be able to access your service via https when your internet is down because it’s terminated at cloudlare’s server. You can still access your service directly without https, or with https but with a self-signed certificate.
Thanks for elaborating. Thats exactly my usecase. You can use lets encrypt certs with a dns challenge I believe. You wildcard a subdomain like *.abc.def.com
Then you set your services to e.g. homeassistant.abc.def.com both on proxy and local dns.
I believe you have to expose your ports once to get the cert and close them immediately. You set the domain to point to the public ip of your router, get the challenge done, close ports and the public domain goes nowhere.
Install the cert, point the local dns to your server ip, done.
If you need more info, let me know.
I don’t know if cloudflare can do this, but I have a different DDNS + Let’s Encrypt setup and I configure my router to set the same local domain as the public domain (in openwrt it’s
local server+local domainalthough I’m not aware of the distinction between the two). So when requests are sent over LAN (or over a VPN) the router points me to the LAN device directly, rather than needing to go through external DNS. HTTPS still works since to the client it’s the same domain as the certificate is linked to.Hope that makes sense as I haven’t fully got my head around it. I just know it works (indeed I just disabled my internet to test, and the services are still accessible over HTTPS).
Replace traefik with this https://nginxproxymanager.com/
If your only goal is working https then as the other comment correctly suggests you can do DNS-01 authentication with Let’s Encrypt + Certbot + Some brand of dyndns
However the other comment is incorrect in stating that you need to expose a HTTP server. This method means you don’t need to expose anything. For instance if you do it with HA:
https://github.com/home-assistant/addons/blob/master/letsencrypt/DOCS.md
Certbot uses the API of your DDNS provider to authenticate the cert request by adding a txt record and then pulls the cert. No proxies no exposed servers and no fuss. Point the A record at your Rfc1918 IP.
You can then configure your DNS to keep serving cached responses. I think though that ssl will still be broken while your connection is down but you will be able to access your services.
Edit to add: I don’t understand why so many of the HTTPS tutorials are so complicated and so focused on adding a proxy into the mix even when remote access isn’t the target.
Cert bot is a shell script. It asks the Lets Encrypt api for a secret key. It adds the key as a txt record on a subdomain of the domain you want a certificate for. Let’s encrypt confirms the key is there and spits out a cert. You add the cert to whatever server it belongs to, or ideally Certbot does that for you. That’s it, working https. And all you have to expose is the rfc1918 address. This, to me at least, is preferable to proxies and exposed servers.