Same issue here - it has never worked with letsencrypt.
I gave up in the end 
same, using without it until they fix it
I think I may have found the problem (In my case)
Checking the log shows…
2017-07-14 22:16:54 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: new_state=<state media_player.living_room_home=off; friendly_name=Living room Home, supported_features=21437 @ 2017-07-14T23:16:54.172914+01:00>, old_state=<state media_player.living_room_home=idle; media_content_id=https://mydomain.ddns:8123/api/tts_proxy/bac9388d0498fb378e528d35abd05792291af182_en_-_google.mp3, media_position_updated_at=2017-07-14T23:11:52.502595+01:00, supported_features=21437, volume_level=0.7300000190734863, app_name=Default Media Receiver, app_id=CC1AD845, is_volume_muted=False, friendly_name=Living room Home, media_position=0 @ 2017-07-14T23:11:52.506981+01:00>, entity_id=media_player.living_room_home>
I can see the mp3 is being successfully downloaded, but trying the https link directly in a web browser gives a DNS error.
Then I noticed the domain is incorrect!!!
Log shows https://mydomain.ddns/8123
Should be https://mydomain.ddns.net/8123
Adding the .net to the link and trying again in a web browser works as expected, so I’m guessing the issue is long domain names?
nah, thats not it, I never tried using mp3s but normal tts from google home does not work, only the inicial turn on chime come on when the device is in sleep mode.
The mp3 file is the sound file sent to google home.
Look in > \HASSBIAN\home assistant\tts
Here is what i get from the sonos log:
[1970-01-21 11:44:35.949] <certval,1> (pass 1) local cert validation failed (27) for hass.mydomain.com
[1970-01-21 11:44:36.397] <certval,1> (pass 2) remote validation failed with result 27 with ttl 300 for hass.mydomain.com
[1970-01-21 11:44:36.398] <ssl,1> SSL connect error -0x2700 11 to hass.mydomain.com
[1970-01-21 11:44:36.424] <certval,1> (pass 1) local cert validation failed (27) for hass.mydomain.com
[1970-01-21 11:44:36.425] <certval,1> (pass 2) remote validation failed with local cache hit 27 for hass.mydomain.com
[1970-01-21 11:44:36.425] <ssl,1> SSL connect error -0x2700 11 to hass.mydomain.com
[1970-01-21 11:44:36.426] <chsrc,0> Transport error ERROR_LOST_CONNECTION for account type 0, URI: https://hass.mydomain.com/api/tts_proxy/9e7609d004e4703e1ae14b532277bb432912fe7e_no_-_google.mp3, friendly name: 9e7609d004e4703e1ae14b532277bb432912fe7e_no_-_google.mp3, share/server: hass.mydomain.com, path: https://hass.mydomain.com/api/tts_proxy/9e7609d004e4703e1ae14b532277bb432912fe7e_no_-_google.mp3, ip: 192.168.10.82, host: hass.mydomain.com, extra info: , http: -1, framer: mp3Is the URI in the log correct?
Can you connect to the file using a web browser?
`https://hass.mydomain.com/api/tts_proxy/9e7609d004e4703e1ae14b532277bb432912fe7e_no_-_google.mp3
The Problem is, that many people forgeth to add the correct port to base_url.
The domain is not correct in this post, but i can open the url from a browser with the right domain.
which version of the domain? I ve tried every single one and none worked
How embarrassing… I left the .net off the base URL 
All working now - Many thanks 
I decided to switch system to HassIO. to see if the problem was in Hassbian .
and with Hassio i get a different error.
2017-07-25 16:13:20 ERROR (MainThread) [aiohttp.access] Error in logging
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/aiohttp/helpers.py”, line 490, in log
for key, value in fmt_info:
File “/usr/lib/python3.6/site-packages/aiohttp/helpers.py”, line 473, in
return ((key, method(args)) for key, method in self._methods)
File “/usr/lib/python3.6/site-packages/aiohttp/helpers.py”, line 426, in _format_a
peername = args[3].get_extra_info(‘peername’)
File “/usr/lib/python3.6/asyncio/sslproto.py”, line 306, in get_extra_info
return self._ssl_protocol._get_extra_info(name, default)
File “/usr/lib/python3.6/asyncio/sslproto.py”, line 547, in _get_extra_info
return self._transport.get_extra_info(name, default)
AttributeError: ‘NoneType’ object has no attribute ‘get_extra_info’
Can anyone figure out what this means?
It shows up when I try to trigger an automation or a script to test TTS on my google home device
1 Like
My installation of Home Assistant on HassIO is logging the same error from aiohttp.access but I’m not using TTS thus it should be related with another component. Anyone could help us on this error? Thks
I figure out what is wrong… it seems the problem is not with ha or letsencrypt, the problem is my router, its a mapping issue. I turn LetsEncrypt on and left it on for a few days, on the 3rd day Google home starting working out of the blue, then a few days later it stops, and now its working again. its the way the router maps the Ip with ssl
2 Likes
I had the same problem. I found the issue is your router. Google “NAT loopback” to find more info about the problem. Basically means that when you are port forwarding to an internal IP, from the Internet you should have no problem going to mydomain.duckdns.org, because it will resolve with your public IP address and the router will NAT it to the local address. BUT… from the LAN side, if you try to access your public IP address the port forwarding will not trigger, so you will end trying to access your public IP, and then nothing happens.
If your router do no support NAT loopback, then… it won’t work.
A solution to your local workstations can be installing up a local DNS and setting the mydomain.duckdns.org domain, using the local IP’s, then setting your DHCP to give your internal DNS to resolve.
And even then google tts will not work, because chromecast has its DNS servers fixed to google public ones (You can not even change the IP address assigned to it, just make DHCP reservations to keep it using the same one every time).
Now, if you use the base url setting with the IP address, there’s another issue with that… this time the certificate will not validate against the IP aaddress, and chromecast will not play the MP3 either.
So… the only real solution is NAT loopback or use plain HTTP.
3 Likes
I suppose that there is a solution without local DNS. I used one more additional “hairpin” rule in my router configuration to solve the problem of accessing services from LAN via DNS name. It described at http://wiki.mikrotik.com/wiki/Hairpin_NAT. Thus I’ve got tts working with LetsEncrypt.
Yes, that’s what I meant with NAT loopback, the problem is that not all routers support that feature. But that’s the only solution to fix the gcast problem with HTTPS.
2 Likes
@Andres_Arenas_Velez Thank you for this! My router not supporting Nat Loopback was breaking both tts and duckdns for hassio. (I’d never heard of Nat Loopback before you mentioned it in this thread) I bought a new router, and everything worked splendidly.
1 Like
THANK YOU FOR THIS POST! I am running a PFSense router that I built using a PC. It does not have this feature turned on by default, but it is an option. I switched it on and its now working for me. Switching on this feature is the ONLY change I made and it worked! I can now move on to setting up the advanced Alexa custom voice control that requires you to use SSL for it to work and do away with the Phillips hue emulation. THANK YOU AGAIN!
I can also confirm the hairpin NAT solved my problem. Although the mikrotik solution above did not work for me, I found one that did.
https://freek.ws/2016/11/21/mikrotik-hairpin-nat-with-dynamic-wan-ip-for-dummies/