Problem with CERT in Alexa Flash Briefings

Configuration
1

I am using SSL, and it is working fine with my regular Alexa setup. When I try to add a Flash briefing, I get the following error:

Oct 23 12:26:08 Pegasus hass[32296]: Error in HTTPServer.tick
Oct 23 12:26:08 Pegasus hass[32296]: Traceback (most recent call last):
Oct 23 12:26:08 Pegasus hass[32296]:   File "/home/hass/deps/cherrypy/wsgiserver/__init__.py", line 2021, in start
Oct 23 12:26:08 Pegasus hass[32296]:     self.tick()
Oct 23 12:26:08 Pegasus hass[32296]:   File "/home/hass/deps/cherrypy/wsgiserver/__init__.py", line 2088, in tick
Oct 23 12:26:08 Pegasus hass[32296]:     s, ssl_env = self.ssl_adapter.wrap(s)
Oct 23 12:26:08 Pegasus hass[32296]:   File "/home/hass/deps/cherrypy/wsgiserver/ssl_builtin.py", line 67, in wrap
Oct 23 12:26:08 Pegasus hass[32296]:     server_side=True)
Oct 23 12:26:08 Pegasus hass[32296]:   File "/usr/lib/python3.5/ssl.py", line 377, in wrap_socket
Oct 23 12:26:08 Pegasus hass[32296]:     _context=self)
Oct 23 12:26:08 Pegasus hass[32296]:   File "/usr/lib/python3.5/ssl.py", line 752, in __init__
Oct 23 12:26:08 Pegasus hass[32296]:     self.do_handshake()
Oct 23 12:26:08 Pegasus hass[32296]:   File "/usr/lib/python3.5/ssl.py", line 988, in do_handshake
Oct 23 12:26:08 Pegasus hass[32296]:     self._sslobj.do_handshake()
Oct 23 12:26:08 Pegasus hass[32296]:   File "/usr/lib/python3.5/ssl.py", line 633, in do_handshake
Oct 23 12:26:08 Pegasus hass[32296]:     self._sslobj.do_handshake()
Oct 23 12:26:08 Pegasus hass[32296]: ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:645)

If I try to pull up the feed in a browser, the URL works fine, and the SSL is showing as valid - I am using letsencrypt.

Has anyone seen this or got it working?

2

I’ve not got it working, but I’m getting the same error that you are! So, that means either there’s a problem or you and I misconfigured the same way!

Oct 23 21:10:32 automation hass[20334]: Error in HTTPServer.tick
Oct 23 21:10:32 automation hass[20334]: Traceback (most recent call last):
Oct 23 21:10:32 automation hass[20334]: File “/home/hass/.homeassistant/deps/cherrypy/wsgiserver/init.py”, line 2021, in start
Oct 23 21:10:32 automation hass[20334]: self.tick()
Oct 23 21:10:32 automation hass[20334]: File “/home/hass/.homeassistant/deps/cherrypy/wsgiserver/init.py”, line 2088, in tick
Oct 23 21:10:32 automation hass[20334]: s, ssl_env = self.ssl_adapter.wrap(s)
Oct 23 21:10:32 automation hass[20334]: File “/home/hass/.homeassistant/deps/cherrypy/wsgiserver/ssl_builtin.py”, line 67, in wrap
Oct 23 21:10:32 automation hass[20334]: server_side=True)
Oct 23 21:10:32 automation hass[20334]: File “/usr/lib/python3.4/ssl.py”, line 364, in wrap_socket
Oct 23 21:10:32 automation hass[20334]: _context=self)
Oct 23 21:10:32 automation hass[20334]: File “/usr/lib/python3.4/ssl.py”, line 577, in init
Oct 23 21:10:32 automation hass[20334]: self.do_handshake()
Oct 23 21:10:32 automation hass[20334]: File “/usr/lib/python3.4/ssl.py”, line 804, in do_handshake
Oct 23 21:10:32 automation hass[20334]: self._sslobj.do_handshake()
Oct 23 21:10:32 automation hass[20334]: ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:600)

3

I solved this using nginx with ssl with proxy, disabling ssl certs in HASS and then using http url in the flash briefing skill, it still defaults to SSL but for some reason it prefers http over https URL.

4

Same problem here, only discovered after the release. Seems that Let’s Encrypt is acceptable for custom skills but not for Flash Briefings. I did a similar thing to what @devdelay suggested, except I only disabled HTTP for the specific route in Nginx.

Here’s my HTTP nginx config now:

server {
    listen 80;
    listen [::]:80;

    location / {
      return 301 https://$host$request_uri;
    }

    location /api/alexa/flash_briefings/ {
      allow all;
      proxy_pass http://localhost:8123;
      proxy_set_header Host $host;
      proxy_redirect http:// https://;
    }
}
5

OK, thanks all, I’ll take a look at configuring nginx.

6

Here’s my Apache config for anyone who still uses apache (apache is running on the same host as HASS w/ a port forward rule from my router mapping 5055 through)…

Listen 5055
<VirtualHost _default_:5055>
# <VirtualHost *:443>
   ProxyPreserveHost On
   ProxyRequests Off
   ServerName box
   ProxyPass /api/alexa http://localhost:8123/api/alexa
   ProxyPassReverse /api/alexa http://localhost:8123/api/alexa
</VirtualHost>

However I have a problem with extreme latency causing Amazon to timeout the connection and give the error response (confirmed this by saving the HASS output to a static text file and serving that to Amazon)… Basically it’s taking between 15 and 50 seconds for HASS to return the briefing content, this is from HASS directly without the Apache or router’s involvement:

$ curl -O http://box:8123/api/alexa/flash_briefings/homebriefing
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   149  100   149    0     0      3      0  0:00:49  0:00:41  0:00:08    40
$ cat homebriefing
[{"mainText": "This is a test", "titleText": "Home Briefing", "uid": "xxxx-xxxx-xxxx-xxxxxxx", "updateDate": "2016-10-23T23:38:39.0Z"}]
7

It looks like the latency issue was at least partially caused by leaving the whoishome example code from the docs active, I guess the template doesn’t handle things very well if there are errors in that templating even if it’s not the block being called.

The other issue I seem to have is that Amazon doesn’t accept ports in the URL, so it looks like it’s going to have to be port 80 to work… which I didn’t really want to open, but whatever.

8

This is what I ended up doing to get it going. Remove whoishome code, Map port 80 -> 5055 on the firewall

Then this to apache to block all inbound requests except for those originating from the amazonaws.org subnet… probably not the best way to do it, but it works for me for now.

Listen 5055
<VirtualHost _default_:5055>
   <Location />
       Order deny,allow
       deny from all
       # if HostLookups would work this should be changed to .amazonaws.org
       allow from 72.21.217.
   </Location>
   ProxyPreserveHost On
   ProxyRequests Off
   ServerName chromebox
   ProxyPass /api/alexa http://localhost:8123/api/alexa
   ProxyPassReverse /api/alexa http://localhost:8123/api/alexa
</VirtualHost>
9

Tried explaining that to a user in another thread about a method not allowed error but he insisted I was wrong about it.

10

With regards to the timeouts issue, it seems to occur after home assistant has been running for a while (like 14 hours), the requests for the flash briefing slow way down to taking up to almost a minute. After it returns, it sometimes returns again right away if run a second time (like it’s cached).

Restarting Home Assistant, the briefings are returned instantaneously… Not sure if this a general HA slow down, memory leak or if it’s specific to the Alexa stuff.

11

Does anyone have a good idea what is causing this issue? Looks like it is something to do with the flash briefing service not accepting the signed certificates. Which is odd since, in my case I’ve tried both startssl and letencrypt.

Someone on the alexa developer forum mentioned a certificate from comodo worked, which implies amazon’s root store for flash briefings is a bit specific. Which has been noted to be an issue with certain versions of the java runtime (the backend for alexa services)

But I’d be interested to see what others have found or if there is a way to make it work without disabling SSL.

12

Finally got around to installing NGINX and giving this another go - still no luck. Can anyone confirm that this is working? If so, what scheme are you using for the URL, what does your URL look like and what do you have for your NGINX config? I moddeled mine after the example @robbiet480 gave.

13

server {
listen 80;
listen [::]:80;

location / {
  return 301 https://$host$request_uri;
}

location /api/alexa/flash_briefings/ {
  allow all;
  proxy_pass http://localhost:8123;
  proxy_set_header Host $host;
  proxy_redirect http:// https://;
}

}

This code should work in your nginx config. However, you’ll need to make sure nginx is running on the same host as HA or change localhost above to the IP of HA.

Second, if HA isn’t running https then you need to change the “proxy_redirect http:// https://” to “proxy_redirect http:// https://”

14

Thanks - did you mean:

Second, if HA isn’t running https then you need to change the “proxy_redirect http:// https://” to “proxy_redirect http:// http://”?

If so I had that wrong.

Seems like I have a more fundamental issue however - I see the incoming request packets coming from Amazon, forwarded by my router but the TCP session is never set up.

I See the SYN
Send the SYN-ACK
Amazon never sends the ACK
Amazon retries the SYN
I retry a bunch of times.

Maybe something in my port forwarding - I’ll keep working on it …looks like my SYN-ACK isn;t getting back to Amazon.

15

Just reporting back on this -

Turns out, Optimum block port 80 by default (but not 443 which was very confusing as that was working fine). My package allows me to unblock port 80 and when I did so everything sprang into life. Thanks for the assistance everyone!

16

Apparently Amazon does not like code 301 response. They want to see only code 200 response on port 80.

I am using this nginx configuration and under the port 80 server section I’ve removed:

return 301 https://$host$request_uri;

and changed to this instead:

server {
    # Update this line to be your domain
    server_name hostname;

    # These shouldn't need to be changed
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
#   return 301 https://$host$request_uri;

    location /api/alexa/flash_briefings/ {
        allow all;
        proxy_pass http://localhost:8123;
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Ports 80 and 443 are forwarded to the host. SSL is handle by nginx per link above. No SSL options are defined in my configuration.yaml under the http: section

17

I am getting the following error with something very close to https://home-assistant.io/ecosystem/nginx/

...request: "GET / HTTP/1.1", upstream: "http://[::1]:8123/", host:...

I moved the part prior to the server to /etc/nginx/nginx.conf where the parent conf is located with http part (with this part as explained in the guide I got some other errors about http not being where it should be)

anyway - can’t get this to work :frowning:

18

Can you post the full text of the error please?

Looks like you are trying to access HA over IPv6 - is that intentional?

19

this is the default config (based on https://home-assistant.io/ecosystem/nginx/)
–> the IPV6 setting comes from there (I don’t know if / why it’s there)
http://hastebin.com/omaxalumem.nginx

the HTTP part I moved to /etc/nginx/nginx.conf
marked # AMIR HASS change
http://hastebin.com/oguyixaxer.coffeescript

the errors: http://hastebin.com/fedovitine.vbs

20

I give up :frowning:

this is my latest attempt
http://hastebin.com/exahurudos.nginx

this is what an attempt to see alex briefing with http comes up with:
http://screencast.com/t/OJ8buQLU

(https redirect works apparently)