DuckDNS and LetsEncrypt in parallel?

Hi,

I’ve just switched to HA OS - mainly for easier configuration of SSL security. And I must say that I’m quite impressed - everything works just fine :slight_smile:

I’m just a bot confused about the DuckDNS and LetsEncrypt add-ons and how they relate to each other. I have so far only installed the DuckDNS add-on, and it took care of everything, so apparently I do not need the LetsEncrypt add-on. On the other hand, the DuckDNS add-on didn’t come with any sensors or whatever, and I’d like to have a bit of control over the certificates (e.g., see when they have been renewed) and maybe even renew certificates manually.

Thus, my question is: Does it make sense to install both add-ons, and what will the LetsEncrypt add-on add in comparison to the DuckDNS add-on? I haven’t found any docs on this (but might very well oversee something).

Thanks
Christian

Duck DNS checks and renews them very regularly.
I’ve never need to do anything

Thanks for letting me know! That’s what I also understood, but I’d still like to see a bit of what’s going on…

Try this integration to get the days to expiry for your certificate.

I didn’t check the add-ons in detail (I don’t use add-ons), but from what I remember the DuckDNS add-on includes Let’s encrypt.

Thanks for the suggestion! I did a quick try, but the installation of the integration doesn’t succeed - error message: Timeout when connecting to this host. I used foo.duckdns.org and port 8123 (as I do in the browser and the android app - with port 443, the error message changes to Connection refused when connecting to host). Any idea by any chance?

I thought that may DuckDNS includes the LetsEncrypt base functionality, but LetsEncrypt might add some additional stuff like e.g. sensors…

Out of curiosity: Why don’t you use add-ons? I’m still rather new to HA, trying to increase my understanding of the advantages/drawbacks of the several installation and configuration options…

just tried the integration with my duckdns address, just the ***.duckdns.org part, port 443.
worked immediately, no errors. can see the expiry date etc.

with your error, do you have 443 redirected to 8123 on your router. Obviously pointing towards the correct device also.

I point 443 to 443 works fine

@csoltenborn
The duckDNS add-on employs the ‘bits of LetsEncrypt’ it needs, Not sure if installing LetsEncrypt separately will interfere with that or it’s settings

I do also use nginx so that I can use both local IP and the DuckDNS remote IP

I did nothing extra (ie. special) and I have a sensor that reports (in weeks) how long to expiry (check for unused entities or just search through your sensor entities)
I also created (from the expiry date) a sensor for how many days to expiry, which I can shere if your are interested.

You should be forwarding port 443 from your router to port 8123 of your HA instance. Then you access it with https://foo.duckdns.org instead of https://foo.duckdns.org:8123.

What sensors do you expect to see from LetsEncrypt? Or asked differently, what kind of information about the SSL certificates is of interest to you and useful?
Personally I don’t care when my certificate expires, as long as it is automatically renewed, why should I care?

My installation type (Home Assistant Container) doesn’t support add-ons. I don’t see any benefits from using add-ons, I can get the same functionality by spinning up my own docker containers (add-ons are just docker-containers configured in a special way to work well in the Home Assistant ecosystem). One of my main problems with add-ons is, that I’m dependent on the developer of the add-on to update the underlying docker image, so for me it’s just an additional layer of complexity with no real benefits. In addition I’m more a code guy than a UI guy.
But for most new users and for users that want easy to configure systems through clicking around in the UI, the add-ons are the preferred way.

On another note, I’d suggest installing a reverse proxy such as NGINX to have https remotely, but keep http access locally, without any certificate errors.

This

only works, because of this

Without NGINX this would not work.

2 Likes

I thought that the DuckDNS integration does not rely on using port 443 (I have only forwarded 8123 to my VM’s IP), and the Cert Expiry integration allows to specify a port, too. However, I have added a port forward for 443 and tried with that port, but same result. It’s a bit weird, since the setup should be fine - I’m accessing my HA instance via https://foo.duckdns.org:8123, and without any issues. Thanks anyways!

yep, as I point out in : -

:+1:

The reason I use 443 is - that is the default for https
There’s nothing stopping you from using your favourite lottery numbers if you’d prefer
Also using 443 externally means i don’t have to specify a port externally

I know :slight_smile:

It was just when I read your post, I interpreted it as “OP forward port 443 to port 443”, which would not be true in OPs case. But as you know, I’m not a native speaker :slight_smile:

Two reasons why I didn’t forward 443:

  • It’s what the DuckDNS add-on sets up, and I didn’t want to play with it
  • I thought it made sense since if I ever want to run an application which relies on Port 443 for whatever reason, I’d be able to do that

What’s the advantage of going over port 443, despite not having to provide it explicitly in the URL?

Well, if everything works as desired, I probably don’t need any additional information. But it comforts me to know what’s happening, and to be able to intervene manually. Thus, I’d like to e.g. know the number of day until expiry, and maybe a button to trigger renewal manually.

But to also make that clear: it’s not a big issue - I’d just set everything up and figured that if I could easily access that info, I’d make use of it while I’m at it.

Add-ons: I see. My environment (TrueNAS) does not support docker containers, so I went for the VM solution with HA OS - that works great so far, and the add-ons have made things even easier.

You can always look in the duckdns log.
Or click on the padlock in the browser and check the date.

Some companies block most ports (mine does at least) and only allow certain ports.

This is where you would setup a reverse proxy like NGINX, which routes the traffic to the respective services all through one port.

I would like to point out that your English, is far better than my “anything else” so any criticism of you would be extreme hypocrisy.
:rofl:

Related: you often claim you are not a programmer. Over a number of years I have worked with many programmers, about half of whom I’d say were much worse than you. So in my book you are in the top 50%. In some areas I’d even say top 20% but that may relate to my weak areas (ie complete incompetence)
:rofl:

1 Like

Thanks for the explanations! In other words, I’m at least 2 applications away from needing something like NGINX :wink: Don’t get me wrong, but I like to keep it simple for now.

I double-checked, and I don’t have such an entity… I guess i will just live without that information - and trust DuckDNS (which apparently does a good job anyways).

I wish I’d set it up sooner, it handles all the certs and forwarding