Summary: Support Thread for Tenasi - CloudflareSSL

DockerHub: https://hub.docker.com/r/tenasi/cloudflaressl

Project: https://github.com/tenasi/cloudflaressl

 

What is CloudflareSSL?

Are you always annoyed by the "this page is not secure" warning, but don't want to configure a custom CA? Then this is for you. CloudflareSSL is a simple docker container that generates SSL certificates for Unraid using Let's Encrypt without the need to expose any ports. CloudflareSSL uses certbot with DNS challenge to authenticate the domain.

 

Getting Started / Configuration

First obtain a Cloudflare API token:

1. Go to the Cloudflare API Tokens page.

2. Click on "Create Token".

3. Click "Use template" for the "Edit Zone DNS" template.

4. Change the token name (optional)

5. Set a specific zone under "Zone Resources" (optional)

6. Click on "Continue to summary".

7. Click on "Create Token".

 

Example configuration:

Make sure Unraid SSL Config points to /boot/config/ssl/certs! Otherwise the container wont be able to update your Unraid SSL certificate.

About Us

GitHub Profile: https://github.com/tenasi

DockerHub Profile: https://hub.docker.com/u/tenasi

Thanks for this it looks like it might fix a use case I have but a couple of questions.

For the "Domains" configuration. Do I need to have a local DNS server running such that I can direct a request for (to use your example in the image above) send requests to unraid.mydomain.com to 192.168.1.6 which is where my unRAID box is? I don't have a domain set up and don't really want to get one could I just add a DNS entry for say "tower.local" to 192.168.1.6 in adguard home or something? I'd rather avoid running a local DNS server completely though if I don't have to?

Secondly I understand this gets me a SSL cert to do https://unraid.mydomain.com on its default port 80.... Would this cert also then be working for dockers running so that say a docker on 192.168.1.6:8000 could also use https://unraid.mydomain.com:8000?

On 1/26/2026 at 5:58 AM, SteamedLobster said:

Thanks for this it looks like it might fix a use case I have but a couple of questions.

For the "Domains" configuration. Do I need to have a local DNS server running such that I can direct a request for (to use your example in the image above) send requests to unraid.mydomain.com to 192.168.1.6 which is where my unRAID box is? I don't have a domain set up and don't really want to get one could I just add a DNS entry for say "tower.local" to 192.168.1.6 in adguard home or something? I'd rather avoid running a local DNS server completely though if I don't have to?

Secondly I understand this gets me a SSL cert to do https://unraid.mydomain.com on its default port 80.... Would this cert also then be working for dockers running so that say a docker on 192.168.1.6:8000 could also use https://unraid.mydomain.com:8000?

If you’re running the simplest setup with no reverse proxy, you don’t need a local DNS server as long as your router supports NAT loopback. Cloudflare will resolve your domain to your public IP, your browser will connect to that public IP, and—if your router supports it—the router will loop the traffic back inside your network and forward port 443 to your Unraid server.

By default:

HTTP uses port 80

HTTPS uses port 443

(You can technically run SSL on any port, including 80, but browsers won’t assume it by default.)

So when you visit: https://unraid.mydomain.com

your browser connects to public_IP:443, and your router forwards that to Unraid.

If you instead visit: https://unraid.mydomain.com:8000

your browser will connect to public_IP:8000. That port must be open on your router and forwarded to the correct internal IP and port. Adding “:8000” tells the browser to use HTTPS on port 8000 instead of the default 443.

To avoid opening a new port every time you add a service, you can use a reverse proxy. With a proxy, you only need ports 80 and 443 open for all your HTTP/HTTPS traffic. From the reverse proxy inward, all other services stay internal.

The proxy looks at the domain name in the request and routes it to the right service on your LAN. For example:

plex.mydomain.com → 192.168.1.6:9000

unraid.mydomain.com → 192.168.1.6:8000

Both domains resolve to the same public IP, and the reverse proxy decides where each request goes based on the hostname.

If you use direct port forwarding to your Unraid server, and this app retrieves the certificate from Cloudflare, then Unraid itself holds the valid certificate and can establish a secure HTTPS session directly with your browser.

If you instead use a reverse proxy, the proxy becomes the device that establishes the HTTPS session with your browser. Because the browser sees a valid certificate from the proxy, you won’t get any SSL warnings. If Unraid also has the certificate and you configure the reverse proxy to connect to Unraid over HTTPS instead of HTTP, then the connection is encrypted on both sides — from the browser to the proxy, and from the proxy to Unraid. That gives you full end‑to‑end encryption.

Just keep in mind that only Unraid is covered automatically. If you want true end‑to‑end encryption for each individual service behind the proxy, you’ll need to configure those services to use the certificate as well so the “last mile” between the proxy and each service is encrypted.

*Trust me, I’m a doctor. Well, not that kind of doctor — but the confidence is the same. And my handwriting proves it.

When updating the SSL certificate for the Unraid WebGUI, does NGINX need to be restarted for the new certificate to take effect? do I need to trigger it manually ?

On 1/28/2026 at 3:03 AM, lyndon said:

If you’re running the simplest setup with no reverse proxy, you don’t need a local DNS server as long as your router supports NAT loopback. Cloudflare will resolve your domain to your public IP, your browser will connect to that public IP, and—if your router supports it—the router will loop the traffic back inside your network and forward port 443 to your Unraid server.

By default:

HTTP uses port 80

HTTPS uses port 443

(You can technically run SSL on any port, including 80, but browsers won’t assume it by default.)

So when you visit: https://unraid.mydomain.com

your browser connects to public_IP:443, and your router forwards that to Unraid.

If you instead visit: https://unraid.mydomain.com:8000

your browser will connect to public_IP:8000. That port must be open on your router and forwarded to the correct internal IP and port. Adding “:8000” tells the browser to use HTTPS on port 8000 instead of the default 443.

To avoid opening a new port every time you add a service, you can use a reverse proxy. With a proxy, you only need ports 80 and 443 open for all your HTTP/HTTPS traffic. From the reverse proxy inward, all other services stay internal.

The proxy looks at the domain name in the request and routes it to the right service on your LAN. For example:

plex.mydomain.com → 192.168.1.6:9000

unraid.mydomain.com → 192.168.1.6:8000

Both domains resolve to the same public IP, and the reverse proxy decides where each request goes based on the hostname.

If you use direct port forwarding to your Unraid server, and this app retrieves the certificate from Cloudflare, then Unraid itself holds the valid certificate and can establish a secure HTTPS session directly with your browser.

If you instead use a reverse proxy, the proxy becomes the device that establishes the HTTPS session with your browser. Because the browser sees a valid certificate from the proxy, you won’t get any SSL warnings. If Unraid also has the certificate and you configure the reverse proxy to connect to Unraid over HTTPS instead of HTTP, then the connection is encrypted on both sides — from the browser to the proxy, and from the proxy to Unraid. That gives you full end‑to‑end encryption.

Just keep in mind that only Unraid is covered automatically. If you want true end‑to‑end encryption for each individual service behind the proxy, you’ll need to configure those services to use the certificate as well so the “last mile” between the proxy and each service is encrypted.

*Trust me, I’m a doctor. Well, not that kind of doctor — but the confidence is the same. And my handwriting proves it.

Thanks this helps and it looks like my router (Unfi) enables hairpin NAT by default. (https://help.ui.com/hc/en-us/articles/30202160464023-Hairpin-NAT-in-UniFi)

However doesn't this mean I still need to enable port forwarding on the router to send port 80 and 443 to the unRAID server (NGIX Proxy Manager docker) however what I want is to ensure that there is ZERO external access to the unRAID server (and it dockers) and ONLY allow internal SSL access to the unRAID (and its dockers). For example I want to ensure that an HTTPS call from my Android TV on the home LAN uses HTTPS to a valid SSL cert on the unRAID docker for that service on the home LAN. No external access at all to unraid or the docker.

I'm thinking I need to set up local CNAMES on my Unfi router DNS server (and/or a local Adguard DNS server) to point https://myservice.mydomain.org to 192.168.1.6 and then on the android TV the service call is to https://myservice.mydomain.org:9995 and the local DNS points that to 192.168.1.6:9995

What I don't understand is how I get a wild card SSL for mydomain.org. I tried registering for a free Duck DNS domain but could NOT get NGIX Proxy Manager to issue a SSL cert for it.

On 1/28/2026 at 3:03 AM, lyndon said:

If you’re running the simplest setup with no reverse proxy, you don’t need a local DNS server as long as your router supports NAT loopback. Cloudflare will resolve your domain to your public IP, your browser will connect to that public IP, and—if your router supports it—the router will loop the traffic back inside your network and forward port 443 to your Unraid server.

By default:

HTTP uses port 80

HTTPS uses port 443

(You can technically run SSL on any port, including 80, but browsers won’t assume it by default.)

So when you visit: https://unraid.mydomain.com

your browser connects to public_IP:443, and your router forwards that to Unraid.

If you instead visit: https://unraid.mydomain.com:8000

your browser will connect to public_IP:8000. That port must be open on your router and forwarded to the correct internal IP and port. Adding “:8000” tells the browser to use HTTPS on port 8000 instead of the default 443.

To avoid opening a new port every time you add a service, you can use a reverse proxy. With a proxy, you only need ports 80 and 443 open for all your HTTP/HTTPS traffic. From the reverse proxy inward, all other services stay internal.

The proxy looks at the domain name in the request and routes it to the right service on your LAN. For example:

plex.mydomain.com → 192.168.1.6:9000

unraid.mydomain.com → 192.168.1.6:8000

Both domains resolve to the same public IP, and the reverse proxy decides where each request goes based on the hostname.

If you use direct port forwarding to your Unraid server, and this app retrieves the certificate from Cloudflare, then Unraid itself holds the valid certificate and can establish a secure HTTPS session directly with your browser.

If you instead use a reverse proxy, the proxy becomes the device that establishes the HTTPS session with your browser. Because the browser sees a valid certificate from the proxy, you won’t get any SSL warnings. If Unraid also has the certificate and you configure the reverse proxy to connect to Unraid over HTTPS instead of HTTP, then the connection is encrypted on both sides — from the browser to the proxy, and from the proxy to Unraid. That gives you full end‑to‑end encryption.

Just keep in mind that only Unraid is covered automatically. If you want true end‑to‑end encryption for each individual service behind the proxy, you’ll need to configure those services to use the certificate as well so the “last mile” between the proxy and each service is encrypted.

*Trust me, I’m a doctor. Well, not that kind of doctor — but the confidence is the same. And my handwriting proves it.

Edited January 29Jan 29 by SteamedLobster

On 1/28/2026 at 7:12 PM, Øyvind Aarhus said:

When updating the SSL certificate for the Unraid WebGUI, does NGINX need to be restarted for the new certificate to take effect? do I need to trigger it manually ?

Øyvind,
Have you figured out how it works with nginx?

Do you need to manually restart nginx or not?

Thank you for this docker app, it works great.