Hi mdok,
NGINX configuration needs port forwarding in the router.
Mine is
80 → 80
81 → 81
443 → 443
So to acces HA from outside now I not set the port and only like: https://xxx.duckdns.org
Hi mdok,
NGINX configuration needs port forwarding in the router.
Mine is
80 → 80
81 → 81
443 → 443
So to acces HA from outside now I not set the port and only like: https://xxx.duckdns.org
I got mine working by simply reflashing HA to a new SD and starting again, not restoring any backups/snapshots, rebuild everything from scratch.
@MickW69 do you have installed DuckDNS addon and have added the ssl certificate lines to the configuration.yaml?
This is the key point. DuckDNS includes the option to move to an https interface, and here comes the issue with the dns missmatch handshake error.
If you can access through http to your fresh install this is why you don’t have any issues now.
I had been using Nabu casa before and after the problem, I kinda figured that I wasn’t “supposed to” need DuckDNS or anything to get it working
Hey guys - just to make sure I got this all right: Currently nobody has a working TTS solution with Sonos while using DuckDNS and Let’s Encrypt?
For me it also failed a couple of weeks ago (probably after an update to Sonos?) - I don’t have any error in the HA but the “connection lost” error in the Sonos App.
I did consider switching to Remote UI via NC, but didn’t want to rely on a cloud service for that (even though it would be more secure as it wouldn’t need an open port…). Doing it just for TTS also appears a bit much, but alas…
I can confirm, that it is still not working.
I can’t get the NGINX addon to work. Everytime I try I get an error:
[10/5/2021] [7:58:09 AM] [Nginx ] › info Testing Nginx configuration
[10/5/2021] [7:58:09 AM] [Nginx ] › info Reloading Nginx
[10/5/2021] [7:58:09 AM] [Express ] › warning Command failed: /usr/bin/certbot certonly --non-interactive --config “/etc/letsencrypt.ini” --cert-name “npm-13” --agree-tos --email “[email protected]” --preferred-challenges “dns,http” --domains “xxxx.duckdns.org”
Saving debug log to /data/logs/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Performing the following challenges:
http-01 challenge for xxxx.duckdns.org
Using the webroot path /data/letsencrypt-acme-challenge for all unmatched domains.
Waiting for verification…
Challenge failed for domain xxxx.duckdns.org
http-01 challenge for xxxx.duckdns.org
Cleaning up challenges
Some challenges have failed.
So I more or less gave up.
Thanks for the feedback! I used this opportunity to activate remote access via Nabu Casa, removed the DuckDNS add-on, deactivated SSL and removed the port forwarding. Took some digging through the logs to clean up atferwards, but appears to be working fine.
TTS with Nabu Casa Cloud to Sonos now works fine (it uses the local IP of HA without SSL: http://192.168.23.6:8123/api/tts_proxy/3935b7c721b3a0d3e8342a635e0f9154f4f5f755_de-de_a9c18110b0_cloud.mp3)
Also seems to be a bit faster now, but that might be wishful thinking… Let’s see how reliable the NC service is.
Just to add to the data. Same problem. I’m an HAOS install running on Raspberry Pi 4 hardware. Sonos worked correctly for over a year up until I upgraded from 2021.9.3 to 2021.10.0. I use DuckDNS/Let’s Encrypt and a pfSense firewall with a loopback configured for the https address. I can control the SONOS devices (volume, playlists, radio, etc), but cannot TTS or play MP3’s stored on my HA device.
After researching this for a while, I think the problem is being caused by two factors that occurred within a few weeks of each other. First, the Let’s Encrypt root certificate server changed from DST Root CA X3 to ISRG Root X1. Subsequently, Sonos seems to have locked down their devices to only accept SSL requests from a certain pool of certificate authorities, DST Root CA X3 being one of them, but ISRG Root X1 not making the cut.
Exhibit 1: DST Root CA X3 Expiration (September 2021) - Let's Encrypt
Exhibit 2: Sonos Developer
Personally, I don’t think this gets fixed until Sonos relaxes their SSL certificate standard a bit. They won’t even accept SSL’s from Sectigo, which is one of the largest SSL providers on the planet. We should all lodge a complaint in the Sonos TS forums. https://en.community.sonos.com/
Wow - great research @RightSpin
But how can it be working for some with the Nginx addon - it is still the same Certificate thats beeing used - or?
Question:
For those of you who have success with the Nginx addon - have you disabled the DuckDNS addon and/or changed hostname.duckdns.org to something new?
@mdok No, after configuring nginx DuckDNS addon is still enabled and using the same hostname. Only had to remove the following lines from config and add the trusted proxy as mentioned above.
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
I’m not sure mdok. I would be interested if those who are working with Nginx are using the Let’s Encrypt SSL or are using something else. I haven’t been able to deduce that from the postings above.
follow. My alarm and doorbell on sonos now fail…
Changing to NC Cloud for external access and deactivating SSL in LAN did the trick for me.
Yes! works like a charm! With duckdns, let’s encrypt & nginx. Port foward adjusted on my router and there it went! YESSSS!
Hey
I also use SONOS and TTS and its not working.
Edit: Using DuckDNS with LetsEncrypt.
Exactly what did you do (what did you add in code and what did you remove). What addon and settings did you add? Router: which ports?
Thanks!
Same here… Same problems…
I am interested in doing what you did…can you share me the steps you made to disable duckdns, SSL and port forwarding? I’ll appreciate this…
It has been a couple of weeks, but I’ll try my very best:
Activate external access using Nabu casa cloud and test if everything works [I use my mobile phone].
Deactivate DuckDNS add-on and remove everything connected to it from config.yaml. Scan all YAML files for references to your duckdns.org domain and reconfigure.
Set internal URL to local IP / DNS name without SSL in Settings, leave external URL open.
Restart and test with new URLs (internal IP:8123 without https)
Reconfigure companion app
Watch log for SSL errors - it should point you to where you might have to reconfigure stuff.
I had tons of SSL errors until I reconfigured all companion apps and everything that tries to access HA via https. Took some time and digging around, but since then everything is fine.
As far as performance goes, accessing lots of data in the local network (graph over many data points etc) seems to be a bit faster, external access is roughly the same performance. So far very good reliability of NC cloud.