SSL with additional domain

Why are you still using DuckDNS if you have your own domain?

Sign up for Cloudflare DNS and you will never ever have invalid certificates or errors even on plain HTTP as they proxy the connection and their certificates will be displayed.

It’s free and are way more than a DNS provider. Here’s the component to update records on Cloudflare (DDNS), you’ll need to create an entity with your IP and an automation which is triggered by a change of the IP entity state and that triggers the cloudflare.update-records service.

Since you have your own domain, get the most out of it with reverse proxy, Cloudflare, etc.

Once you’re in Cloudflare they’ll provide you with very easy to follow instructions on how to change the name servers from your domain provider so you can use Cloudflare DNS with your current provider, alternatively you can move your domain to Cloudflare.

I made a post a while ago about this:
https://community.home-assistant.io/t/reverse-proxy-cloudflare-access/159182/2?u=gurbina93

1 Like

Hi can you please post the correct link. The above is not working

1 Like

I’m just gonna copy paste it here, it should give you a good idea on what to do:

Well, it’s quite straightforward once you setup the Cloudflare component which I guess you already did.

As for LetsEncrypt replacement, I am using NGINX Proxy Manager.

You install it, do port forwarding for 80 and 443 from your router to this add-on ports as per the instructions and start creating your “Proxy Hosts” entries i.e. for homeassistant:

Proxy Host: homeassistant.yourdomain.com
Destination: To your Hassio IP on the correspondent port, in this case 8123 for Homeassistant.
And select the right incoming protocol (HTTP/HTTPS), I guess you’ll start with HTTP to get it working first then you can switch to full HTTPS later on.
Fiddle with the remaining settings, they should be quite straightforward.

Reverse proxy grants you the power of having subdomains so you can forward plex.yourdomain.com to your PC Plex instance, ha.yourdomain.com to your HomeAssistant instance on an RPi, and so on. You get the idea.
Now as for the benefit of NGINX proxy manager it already has LetsEncrypt embedded in a nice interface, basically it takes one click to get your certificate…

But since you’re using Cloudflare you can use the Origin server certificates offered by them which are valid for 15 years so you don’t have to worry about renewing your certificates or about getting LetsEncrypt to successfully complete the challenge for issuing the certificate. You can download them from SSL/TLS -> Origin Server tab on the Cloudflare console and upload them into the NGINX Proxy Manager.

In my case migrating it was quite straightforward since I was using a new domain name and using subdomains, so I left my old setup running (using DuckDNS) until I got the new one up, beware you’ll have same some certificate errors depending on which URL you use and the base_url entry in your configuration.yaml, however you can just click on continue visiting the website despite the certificate error.

Steps for migrating:

  • Setup NGINX
  • Upload the origin certificate from Cloudflare (wildcard cert so works for any subdomains)
  • Add the proxy hosts entries for the old and new setup
  • Switch the port forwarding correctly

So you will have your old setup running while you create/test the new one or until you figure out what do you want to do with it (which services to expose, which subdomain names, only specific pages from a service, etc).
If you’re not using full HTTPS end to end, you will need to change the setting in Cloudflare console SSL/TLS to Full or Flexible. Once you have it up and running, including the origin certificates you can switch to Full (Strict). If you don’t do this you will most likely run into a lot of certificate errors on your browser or bad redirection.

My advice is to also configure your router to drop any connections not coming from Cloudflare for security.

Cloudflare will be the proxy, your IP will never be exposed and anyway anything coming to your public IP that is not proxied traffic will be dropped. You can start adding more stuff on Cloudflare like security rules for DDOS, stop bots (like the ones from Shodan), challenges for risky IPs like (like the ones you get from websites to prove you’re not a robot), etc.

One very useful feature to completely secure my setup that is WAY more useful and important than Fail2Ban or whatever is the Cloudflare Access.
So it’s like a 2 step authentication, whoever tries to access your instance will have to authenticate on Cloudflare Access before being able to reach your instance so you can drop the fail2ban.
And you can stop worrying about DDOS, bots, unauthorized access to your instance, etc. Cloudflare will be your Firewall and your router should only allow traffic coming from Cloudflare.

The only exception is if you have a standard VPNs, these cannot be proxied through Cloudflare so you will have to turn off the proxy feature for that specific DNS entry in Cloudflare. I think there are certain VPN protocols like WireGuard which are exempted from this.

But for starters you can start with HTTP basic configuration on HA on port 8123, it will still show as HTTPS when you reach your instance, but the connection between Cloudflare and your instance will be plain HTTP so beware.
To get full HTTPS you will need to upload the Cloudflare origin certificate and setting HTTPS as your protocol in the NGINX reverse proxy add-on; setting your base URL valie in the HTTP section of the configuration.yaml with HTTPS i.e. https://ha.yourdomain.com and setting Cloudflare encryption to FULL STRICT.

10 Likes

Wow, thanks a lot. A lot of work for me now :smiley:

I have now communicated to my host provider to change the DNS to cloudflare, and then will start as you suggested.

Actually this I hope can help in the following.
Since long I wanted to host my own servers (video/audio Jitsi server, nextcloud instead of dropbox, and so on), all self hosted in my office.

But I was unable since in my Small office I have only 1 dynamic IP.

A lot of the installation of those servers are done for an exclusive IP with Letsencrypt and access from port 443 (some also need port 80): so everything works fine if I have ONE server only: i.e. I forward port 443 and 80 from the router to the local address of the server, and the installation of thje server handles the letsencrypt, and everything works perfectly.

But the moment I want to have 2 or more servers I have big problems (I tried to work with Nginx proxy manager settings for long time now, but always failed, I also tried Caddy but is sooo complicated to me and always failed)

I guess with your solution this can be overcome, if I do as below, right?

Forward port 80 and 443 to my HASSIo 192.168.1.4:8123, and then Nginx proxy manager WITHOUT Letsencrypt SSL and use cloudflare instead

serverone.mydomain.com to go to http://192.168.1.1 and use certificate downloaded from cloudflare
servertwo.mydomain.com to go to http://192.168.1.2 and use certificate downloaded from cloudflare
serverthree.mydomain.com to go to http://192.168.1.3 and use certificate downloaded from cloudflare

and of course
hassio.mydomain.com to go to http://192.168.1.4:8123 (at the moment I am using xxx.duckdns.org)

1 Like

Great, wow! Thanks for this!
I’ve got it to work now with Cloudflare component with HA and Minecraft server in same domain. My kids got little upset when changing to Cloudflare, the mincraft traffic was not proxied since Cloudflare only proxy HTTP and HTTPS traffic. It’s solved now, and I have promised them not to fiddle any more until the school starts again.
Once again thanks!

Correct, you’ve got it all right.

Install the NGINX Proxy Manager the one with the UI, much much simpler. I was also never able to get the normal NGINX reverse proxy or caddy to work the way I wanted it to work.

Port forwarding 80/443 from router to your Reverse Proxy add-on, it’s on the same ports if you use the NGINX Proxy Manager add-on on your HomeAssistant host.

The rest is exactly as you described.

1 Like

Yes I use nginx proxy manager hassio addon already

Only now I have a doubt: since all this server installation have a script (possible to do without but it would take me a week or more to get it rigth :stuck_out_tongue:) … if I do NGINX proxy manager WITHOUT SSL (not letsencrypt and not cloudflare), and I let the server installation script do the installation also of Letsencrypt … will it then work? I mean the nginx proxy manager is then a simple “passage” does nothing, and hence it should work?

Or am I obliged to do cloudflare on the Nginx proxy manager, and then try to do the server installation without any certificate (hoping that it works) ??

I hope I am clear

Not sure what exactly is your situation, could you give more details? Mind explaining how it works or what’s the logic behind the script and what it does (only what is relevant to the network issue you have)?

Seems like you’re setting up servers and they use LetsEncrypt and do the LE challenge?
Or like there’s a service that will need to reach back to these servers once they’re installed?
If so how’s that service reaching back to the server? By IP? By hostname?

NGINX will let it go through even on simple HTTP as long as any incoming request to NGINX matches any proxy host entry. Or you can also use redirect/rewrite which sounds more like what you’d need to do depending on your needs.

Thanks for your time and help.

I am trying to make a Jitsi server inside my LAN accessible from outside, and of course that it will work audio and video for all participant.

If I forward 80-443 port from router to the IP hosting the server (with a standard installation including lets_encrypt,) everything works.

If I use HASSIO with nginx proxy manager (I want my HASSIO Server and Jitsi server both working) with lets_encrypt and forward myvideoserver.duckdns.org to the internal IP of the server is not working.
Either if I install with or without lets_encrypt.
Exavtly what the script does I have to investigate

Below is the scheme of the server and which ports uses (scroll down in the webpage)

So I checked the docs it should work fine with NGINX, LetsEncrypt isn’t mandatory. You can stick to using NGINX and the Cloudflare origin certificate.

When you access your jitsi server locally, what URL do you use? Is it HTTP or HTTPS? I’d try to get it working on simple HTTP first before jumping into any certificates and HTTPS which might be the issue.

You can even leave Jitsi in HTTP since all the traffic from Cloudflare to your NGINX is HTTPS, and only the traffic between NGINX and Jitsi would be HTTP (which is local traffic), you can always amend this later on.

Seems like there’s a mismatch in protocols somewhere or a certificate error that doesn’t let you get through.

Just drop me a message with the details on how you access your Jitsi server locally (URL, protocol, port) and the proxy host entry details. Also of any errors displayed on the browser when it’s not working.

Maybe Jitsi is using websockets and they’re not enabled in the NGINX Proxy entry?

I’ll see if I can spin up a VM and try to play with Jitsi, looks like quite a cool conferencing tool to play with.

1 Like

Will try your suggestions.

Yes Jitsi is the best, and has end to end encrypted video and audio

Thank you for sharing this informaiton. I transferred from duckdns to my domain in about 3 hours of “playing” following your tips.
The 15 year certificate really is a winner…no messing around with verification and validiations etc…
I took a different approach on the cloudflare dns record updating. I decided to run this docker because i didnt want to relay on HA to update it. Reason being that as most I mess around with it frequently and if it’s down, then update is down. Very simple docker to run.

Wanted to ask you about the Cloudflare Acess and how does it play with your cloud stuff i.e. alexa, google etc.

Thank you again

It works great with Google Assistant and Uptime Robot.

In the case of some of these services the provider might give the source IP range they’re using so you can just add it to a bypass rule, like Uptime Robot.

I just went with a simple approach for Cloudflare Access on HomeAssistant, set the access policy you just to:
https://[YOUR HOME ASSISTANT URL]/auth/authorize

All requests made your instance will be redirected to this URL unless they are authenticated or they’re calling an API or some other resource, for example Google Assistant API is located under:
https://[YOUR HOME ASSISTANT URL]/api/google_assistant

For LetsEncrypt is:
https://[YOUR HOME ASSISTANT URL]/.well-known/acme-challenge

Based on the rule as I have it, it will work for these two.

I advice you to use Firewall rules and block bots by default, challenge (or captcha) low to medium risk IP (10-20) and block high risk (30). This will get rid of all nasty bots and anything from know malicious IPs, nearly all the bad traffic is bots (about 150-200 request made by bots are blocked daily by this rule).

The bright side of all of this is that to get through they’ll need to pass through Cloudflare and even if someone had your IP your NGINX will reject connections unless it matches a proxy entry. I’m no security expert but I guess this alongside HTTPS full encryption, DNSSEC and so on make for a good deterrent. Since I’m no pentester or security expert I’d like to hear from someone who knows better, but as an IT consultant it seems sufficient.

According to Cloudflare example you can whitelist bots as per below but I haven’t tried it:

Here’s all about the Firewall rules, it looks complicated but it’s all GUI based and very simple… The only thing is learning the variables you can use and the possible values which you can find here:

There’s a parameter to whitelist “good bots” or if you’re like me I block all bots (default if you enable it) and exclude the ones I use like Google Assistant, Uptime Robot, etc.

For LetsEncrypt and Google Assistant this works for me:

It’s very important to know that if your LetsEncrypt certificate isn’t working anymore when using Cloudflare it is very likely due to Cloudflare Access or the Cloudflare Firewall.

You can always bypass all of this by turning off the proxy feature for that DNS entry like below (grabbed the image from the Google, not my domain):


It is the orange :cloud: (Cloud) icon with arrows. You can use this as a quick fix to tell if something in Cloudflare is the issue or if it’s somewhere else. For some services you’ll need the proxy feature disabled like most classic VPN protocols.

1 Like

once again thank you very much… a lot of information to digest. I went with your origin certificate tip, so I now have a 15 year cert working :grinning: via nginx. All working great with full (strict) connection.
would you mind sharing a snapshot of your badbots rule. I found some examples on the web, but they use the “contains” parameter with a specific name.
I understood from your note there’s another way to block them?

I block all known bots:

Then on other Firewall rules and Cloudflare Access I exclude the ones I use like the one used for LetsEncrypt, Google Assistant, Uptime Robot, etc.

thank you again. this is a very cool learning experience.
I tried some (firewall rules) from the web and you can then go into the logs and decide what to let in or not.
Again thank you

Hey @gurbina93 this is pretty cool, thanks for this. I decided to buy a domain and migrate over to a cloudflare setup recently and stop using duckdns.

I was hoping you could answer a few questions though if you don’t mind. Cloudflare has a ton of options so was hoping to get help from someone that has it figured out.

  1. You said in your earlier post that Access is one of the big benefits but I’m not really sure if I get why. It seems like the purpose is to add an authentication layer to your app but my app already has an authentication layer. Other then the /webhooks URLs which can’t be locked down and the login screen, everything already requires authentication. So what does Access provide in this situation? The firewall I totally get, that’s great. But yea I’m confused what Access adds over that.
  2. In the Settings panel of Firewall there’s an option for Security level which can be set to Low, Medium or High and an option for Bot fight mode which can be turned on or off. Do you know what either of those do? I assume they are basically like OOTB firewall rules but its not really clear how they translate into firewall rules.
  3. Do you use the rate limiting feature? This is actually the feature i was most hoping for since it seems like a much better version of fail2ban. Sadly it isn’t free so I’m trying to determine how much it will actually cost. Wondering if there’s a way to ignore authenticated traffic since I really just want to rate limit the unauthenticated traffic and there’s far less of that.
  4. Do you use the caching or auto minimize features? I have them turned on right now to try them out but I feel like Lovelace UI doesn’t like that, I’ve seen a bit of wonky behavior where I have to refresh more then I used to and wondering if that’s the cause

[EDIT] Also let me know if you’d rather I PM you or put this on a different post. I know its kind of unrelated to the topic but it seemed like this topic had become mostly about how to use cloudflare at this point already so figured I’d just reply.

So…

  1. It’s 2 step factor authentication which will require access to whatever you link it (like your email, Facebook account, etc) to not just a single username and password, you can also have 2FA on HomeAssistant but I’d rather have people be stuck at Cloudflare Access portal than reaching my instance.
    I linked mine to my email address, Facebook and Google. So I can login with Facebook/Google on just 1 click, and as a fall back I have the email 2FA (since my workplace blocks Facebook for example or if the site goes down).
    Added advantages are:
    Visitors and bots don’t know what they are hitting, they will hit the Cloudflare portal.
    Even if you had 2FA in HomeAssistant and they can get to it they can already see it’s a HomeAssistant, PLEX, Nextcloud, etc instance and that’s info that can be used against you. So if bots don’t know what’s services are running on your domain since they hit the Cloudflare Access portal that’s a good thing, isn’t it? You won’t see your HomeAssistant showing up on Shodan or some other sites. And anyway I feel safer knowing they’re hitting, getting stuck or cracking Cloudflare servers and not mine.

Aditionally you can see whatever or whoever is trying to get in on the logs, you will see the IP address, the email or Facebook account linked, dates, state (allowed, blocked), authorization status, etc. You can revoke these active authorizations.
This gives me better control over who has access to my instances and who is using it, just a personal preference.

  1. It’s on the help button next to the options here’s what each one of these do:
  • Essentially off: Challenges only the most grievous offenders
  • Low: Challenges only the most threatening visitors
  • Medium: Challenges both moderate threat visitors and the most threatening visitors
  • High: Challenges all visitors that have exhibited threatening behavior within the last 14 days
  • I’m Under Attack!: Should only be used if your website is under a DDoS attack
    • Visitors will receive an interstitial page while we analyze their traffic and behavior to make sure they are a legitimate human visitor trying to access your website

I have mine on High, I never have issues accessing my instance. When I do I see some waiting page that says I have to wait 10 seconds like this one or even a proper challenge:

The one for the bots it’s to fight bots like the one from Shodan or any other bot scrapping the web/ports, even Google Assistant, Uptime Robot, etc are considered bots.
This is good personally I don’t wanna see my domain showing up there with whatever I am running if it got exposed like HomeAssistant, PLEX, NextCloud, Unifi, Tranmission, etc.

  1. Since I have my instance blocked with Cloudflare Access and strict Firewall rules I don’t see this necessary, it’s for family and friends use and not open to the public in general so I don’t see how rate limiting benefits me, they’re trusted clients which require authentication so I don’t see them as a threat trying to hit me like that.

  2. Standard caching but I haven’t seen any benefit, I am just running with defaults. The auto minify feature will break some functionalities in HomeAssistant, specially script related. I tried some of the others like Brotli (no issues there), HTTP2, Rocket Launch and others but they didn’t seem to help much or broke stuff. I haven’t tried any of these for over 16 months so not sure if they will work now.

Anyway take everything with a pinch of salt, this is just my personal views, I’m no expert on the field but it works for me and I have seen some major changes on the incoming traffic and IPS alerts I get.

For #1, I get what you mean about stopping people at the access page so they don’t know home assistant behind it, that does sound like a plus. My main concern though would then be all the HA communication that can’t handle this extra layer of authentication being injected.

Like as a human I can deal with two login screens. But then I assume I would need to let everything coming in over /api/* to bypass since any code trying to communicate with the API would not be able to handle this unless I could modify it to include a generated security token from Access, which I won’t be able to in most cases. And what about mobile apps, can they handle an extra layer of authentication injected in like this? Do you use the HA mobile app? You mentioned Plex, Plex has lots of apps for various devices that require login. Do they still work with cloudflare access in front of your Plex server?

For #2, let me clarify. You mentioned specific firewall rules earlier about blocking things with threat level >30. I was curious how those rules compare to the Security level setting, like if threat level is also what that looks at for who to block and challenge or other factors. And the other rule you mentioned was blocking all bots which sounds a lot like bot fight mode.

Anyway basically just trying to figure out if one or the other was redundant. Probably a question I’d have to ask cloudflare support though.

For #3, I was thinking rate limiting would be useful for preventing floods to your server. But yea I realize now that’s redundant if you have cloudflare access turned on, unauthenticated traffic never gets to your server in the first place.

For #4, thanks! I’ll turn off the auto minify options then and leave the others for now.

  1. Yes, you can let these services bypass the Firewall and Cloudflare Access. You can do it by whitelisting the providers IP or by URI, there’s also other ways to whitelist them or bypass them, there’s tons of filters for that. I can help you with the rules to get it sorted out.
    Cloudflare Access works great with the Ariela app and also the official HomeAssistant app on Android, I think I recall one guest using it on the iOS version and he had no issues. They’ll get a pop-up with the Cloudflare Access like accessing over a web browser followed by the HA sign-in page. Once you log in it will go back to the HomeAssistant app and work as usual, you only do this the first time you log in. The authorization token will remain active on the device unless you revoke it or set it to expire within certain period. For Nextcloud I think I do have issues with the mobile app as it tells me my server it’s malformed but works fine on the web browser. I actually I need to look into this, find a way to fix it.
    For PLEX it seems to be working fine.
    Seems like some of these apps will open a browser for authentication or are just an iframe or whatever you call them like web browser viewer inside the app so basically so no issues with Cloudflare. I think Nextcloud app uses native login so that’s why it doesn’t work with it. Haven’t found a way to get it fully working, I just tried something and got the Cloudflare Access to show up but now upon entering the code it takes me back to the apps and craps out with this error:

  2. That’s right, moreover you have the firewall too.