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.
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 : -
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 
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
Two reasons why I didn’t forward 443:
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.
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)
Thanks for the explanations! In other words, I’m at least 2 applications away from needing something like NGINX 
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
Huh ???
Not sure then … but I have a sensor : -
sensor.cert_expiry_timestamp_home_assistant_io
Which does not appear in any of my yaml config so I just assumed it turned up with DuckDNS
I certainly don’t. Maybe because of the type of your installation (Home Assistant IO)? But doesn’t sound too likely, I guess…
I run three instalations, one core, but primary and major test are both HassOS (one NUC one Pi4) both HassOS have this sensor.
You can create such an sensor
Thanks for this, I don’t remember doing it but I must have
