How to Configure Remote Access with Let's Encrypt

I tried to get remote access working and found a lot of the guides to either be a bit outdated, or not applicable to me. Most examples use Duck DNS. This is because you’re going to want to use HTTPS, which means you need a SSL certificate, which means you need a domain to certify. That’s what Duck DNS will do for you; it provides you with a domain that you can certify. Of course, you also need this domain so that you have a reliable address to connect to since you likely have a dynamic (changing) ip address.

But I already had a domain from freedns and didn’t want to do the Duck DNS route. The difficulty I had was that the Duck DNS addon method somewhat automatically seems to take care of a number of other steps for you, with Let’s Encrypt etc., so it’s not as simple as skipping the Duck DNS part of these guides.

So, if you’re like me, and don’t want to setup a new hostname with Duck, then follow along. If you don’t mind using Duck, then by all means use that addon and those guides. It’s probably easier.

Get a SSL certificate with Let’s Encrypt Addon

  1. Install the “Let’s Encrpyt” addon. I’ll assume here you are running Supervised HA and have the addon store. This is going to generate you a certificate for your domain name (that you already have).
    Starting this addon runs the certbot program to reach out and get you a certificate. Before you can start it, you have to enter in the config.


  • The challenge option can be http or dns. The dns option is a bit nicer, but only supported by certain services (not mine)
  • Enter your domain, your email


  • Here you need to define the port you plan to forward to from the outside for generating the certificate. My HA server already had something on port 80, so I set it to something different
  • Forward port 80 on your WAN side to the port you defined here
  1. Start the addon and go over to the logs. Keep refreshing to see the progress of the cert generation. If you’ve forwarded the port correctly, you should get a successful result and the addon will shutdown. It says that certbot will have to re-cert periodically, which you can do by setting up an automation (not covered here). Also, when starting the Let’s Encrypt addon it will check for recert, and exit afterwards.

Port Forward your hostname to your HA Server

You’ve already now port forwarded port 80 for the cert bot, but now also port forward your WAN IP to your HA server’s ip, port 8123 (standard HA port).

Test this worked by going to in your browser. At this point, your HA server is still using regular HTTP, so the work you’ve done with Let’s Encrypt isn’t coming into play yet. So if you have problems connecting via your domain it is because your port forwarding isn’t working, or your domain isn’t resolving to your ISP IP address.

Enable HTTPS on your HA Install
Home Assistant needs to be told to use https, which you can now do since you have a cert. To do this you have to add the following to your configuration.yaml:

# enable https 
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

You must restart your HA server for this to take effect. Once you do, you will no longer be able to connect with regular http:// connections. Locally, you have to use, or https://yourlocalipaddress:8123.

Configure your Companion App

You’re likely doing this so you can access HA from your mobile phone, so you’ll want to configure your phone’s App. Go into the Configuration | Companion App menu and update your internal and external addresses to both be your domain address with the port. Note that this means when you’re on your local network using your phone, it may be connecting out through the www first, which isn’t efficient. You can correct this by re-directing. I’m using AdGuard (excellent pi hole alternative), to do a DNS rewrite, which tells my internal devices that when they’re trying to resolve my HA hostname, to point to my internal IP.

If you do not give the companion app the hostname, and give it your internal IP instead, it will tell you the certificate is not valid. This is normal behavior because the certificate is for your hostname only, and cannot be for your internal IP address.

There you have it. You can now connect remotely using your previously created dynamic hostname.


great tutorial.

What if you already have certificate generation with DuckDNS addon and you would just like to add own domain?

Not sure what you mean by “add own domain”?

1 Like

Nice tutorial, very straight forward.
I’ve setup SSL for my setup just in few minutes.

I’ve just managed to get Let’s Encrypt with NoIP and UnifI controller working.

Thanks, works for me! I’m now able to access https://externaldomain or https://internalip within a browser. But on the companion app (both android and iOS), it gives me a certificate validity error (1202). What should i do?

Only thing I didn’t follow on your guide was to portforward the port 80 (because i can’t, but i do have the porforward on the 8123)

The strange thing is that if i open the certificate on the web browser, it still contains reference to the duckdns domain (which i removed since i’m not using it anymore)

1 Like

I have the same issue. I think we need to use AdGuard DNS rewrite. But I don’t know how to do so :wink:

I ran through the logs and saw that letsencrypt was indeed having problem generating the certificates because of port 80 error (that’s why old duckdns ones where still present and thus not valid).

Since i couldnt do that port forward (80ext->80int), I surrendered to use duckdns.

In your AdGuard portal go to Filters | DNS Rewrites and add it there.

I rewrite my FreeDNS url to my local IP address. This lets me continue to connect to HA via the https://url, which it expects, but doesn’t send the traffic outside my network, which is inefficient.

Seems to me you need to add a section about automating certificate renewal. I suppose manually running the LetsEncrypt addon on occasion would suffice, but this whole project is all about automation. I didn’t like most of the solutions I found searching the web, so I designed my own. I’d try to explain it, but I figure I should first wait until my certificate is due for renewal and test to be sure it works as expected.

Newbie here, and a bit stomped, or not (not sure if I should be :-)) about the outcome of applying this.

My setup: HA OS on a raspberry pi4, accessed via Chrome on Mac, or the native iphone app, on the latest release.

The good part: clear and useful, and I got now encrypted access both on laptop & iphone.

The thing I don’t understand is the port part, though. Even though I followed all the steps above, I have to add the 8123 port everywhere (laptop, iphone on & off wifi). If I leave out the port forwarding rule for 8123 on my router, I don’t have access anymore. If I leave out the port on 5G iphone, I don’t have access or I get a SSL error.

So, what should I do? Leave it all working with port 8123, and remove port forwarding for 80 and 443?

TIA for your help.

The port forward for 80 is required if you are using the http challenge option and not required otherwise. You should not remove that port forward if you use the http challenge because you will need to renew your cert periodically, which requires performing another challenge.

The instructions don’t say anything about port 443, so I’m not sure why you forwarded it, but I can speculate that you want to use it because it’s the standard HTTPS port. That having been said, based on my experience, you can’t have the same hostname and a different port for internal and external connections even if you use port forwarding on your router (such that, in your case, inbound 443 connections from the Internet side would go to 8123 of your HA device). If it is possible, it didn’t work right on the version on which I tried, or I simply couldn’t figure out the appropriate combination of settings in the “Home Assistant URL” section of the network settings. That having been said, you can change the port in the HA config (this might require YAML editing, I don’t remember), so if you want to use 443 for everything and 8123 for nothing (such that 443 forwards to 443 vs forwarding to 8123), that is an option, but it will require reconfiguring all clients that are already connecting, so if you already have functionality at 8123, it could be a lot easier to leave it there and get rid of the 443 forward.

any success with your method?

Starting the add-on essentially triggers a renewal iirc. So an automation with a time-based trigger that actions a service call for running the addon should do the trick?

Yes, you can just run it once a day, assuming it won’t renew until the cert is a certain age. IIRC, that’s how certbot works, and a scheduled task or cronjob is recommended. My solution is a bit more over-engineered, for practice’s sake, because HA is an automation system. I fully expect it to work, but I have it set to trigger with only a week remaining because I’m hoping to see an e-mail notification from LE before that, and then I can adjust my automations to precede that e-mail in the future so I know there’s a problem if the e-mail shows up. IOW, I don’t know yet.

Step 1 was to reach my home assistant VM through (replacing mydomain with my actual domain name).

Step 2 was to set up the Let’s Encrypt add-on.

It’s not clear from the interface that you are supposed to enter your domain name next to the “X” below options. However I figured it out eventually and entered it as

II have no idea why the e-mail address field is hidden instead of plain text.

I left the two cert names as they were and left the challenge as http:. Under networking I entered 8123/tcp.

When I hit the save buttons, they turn into a green checkmark for a second, then fade to a grey “save” button.

This is where I discovered that the http: challenge requires port 80 to point to the HA VM. Once I did that, I went back to the Let’s Encrypt add-on and clicked on start. Everything then worked.

My automated renewal testing is complete. Because laying it out in an instructive way took a significant amount of space, I’ve documented it as a separate guide here.

Hi all - wanted to say thanks to @nicesocks for this useful guide.

I run HA in a docker container so I don’t have add-ons but this guide was still useful. My approach was to use a letsencrypt duckdns docker (maksimstojkovic/letsencrypt if anyone interested).

I wanted to ask about the Adguard DNS rewrite approach as I have adguard home running on my network. If you add a rewrite rule then this is too broad as all lan side service/request will be rewritten to the local IP of my HA.

So I made the rule much more tight using: and this seems to be working fine. Hope this helps others!

My question is that I see a load of adguard query logs that are related to HA but are not https and these do not get rewritten so I don’t think my approach is working perfectly.

Anyone have any suggestions/thoughts? I’m thinking that I need to use a dedicated ddns name for HA and then use the rewrite rule to rewrite everything for this ddnsname.

Update for the previous post…

I have solved the rewrite issue by doing the following. In summary, it works better if you setup HA on a sub domain for - I have used but anything should work. Here are the steps.

  1. create a new ssl certificate with wildcard enabled (this was not the default for the docker letsencrypt tool)
  2. change the HA internal and external network url to
  3. configure HA to use the new certificate (edit config.yaml)
  4. restart HA for changes to be updated
  5. change browser login to and check all is working
  6. do the same from HA app is used. Go to companion app settings and update server details.

Once all this is done and working, just go to adguard GUI and change the DNS rewrite rule to