SSL / HTTPS Streams

MedwayRadio

New Member
Can you tell us what the situation is with SSL/HTTPS streams as it relates to services provided by InternetRadio.
I ask because I'm trying to build Skills/Actions for Voice Assistants to play my stream. for example Alexa Dev immediately throws an error if a HTTP stream is specified during build.
Looking at the changelogs for Shoutcast/Icecast/Centova Cast, all support SSL/HTTPS at their current builds although Shoutcast 2.6 doesn't look like a good move at the moment
 

MedwayRadio

New Member
Thanks for replying.

Any timescales to support https? I appreciate this may take a while having seen discussion elsewhere re: recent changes to Shoutcast and possible additional costs.

However getting a skill / action up and running asap is a bit critical for us for a reason which I can't go into here at the moment.

Soooo...... Looking for a workaround (bear with me, at the bottom of a learning curve here)

I have read that it's possible to do a http to https conversion using http/https reverse proxy. Can you see any pitfalls that you are aware of in taking this approach.

The concerns I can think of is that stream performance will be affected however I did see an article on skill building, setting up a proxy on AWS, so may not be an issue. I am cursing as I didn't bookmark it at the time and for the life of me can't find it at the moment

Another concern is does proxy circumnavigate geo fencing I have in place at the moment ?

Would appreciate any comments on this
 

More Support

Level 2 Support
Staff member
It might be your lucky day... I've had a look at some of the centova cast internals and I have something for you to try in your Alexa implementation:


Basically I've modified some of the Centova's Nginx web proxy configs to enable SSL. We already have SSL on every server but for some reason Centova only uses it for the web server running on port 2197 that displays cover art in the widgets and control panel. I've added the SSL config to the web proxy on port 443 and it seems to work. Check the above URL and let us know how you get on. If it works out well I'll roll it out to all servers. / accounts.

To answer some of your questions:
Performance should be fine as the proxy is running on the server itself. Had you proxied from a different server there could be issues if connectivity between the proxy server and our server isn't 100%. If the above local proxying works out then this isn't an issue.

Using a proxy would unfortunately circumvent Geo Fencing. Any ip blocks done within the shoutcast admin should work as the proxy correctly implements the X-Forwarded-IP header which Shoutcast reads correctly.
 

MedwayRadio

New Member
Many thanks for this, very much appreciated. :)

Firstly the stream shows as a https stream in a browser which should sort out mixed content issues which I think others have raised in the past.

Secondly the provided stream has allowed progress through the skill build. I can now hear my stream when I test. I have some errors to sort out which I think are not stream related, before I can publish/certify. Certification takes a few days as I understand it. Will let you know how I get on
 

More Support

Level 2 Support
Staff member
That's good to hear :D Do let us know how you get on with your Alexa integration. I'm sure it will be of interest to other Internet Radio broadcasters.
 

MedwayRadio

New Member
Just a quick update

Testing is taking longer than expected. On the development consoles it all seems to work ok, but on a real device, an echo in my case, I get a silent stream after using once i.e. get it to work once but not subsequently. So some more investigation on my part is required. Interesting to see the dev console showing up as a listener from Estonia!

Certification is also more involved than I thought, there's a checklist to go through to have chance to get the skill certified for publication.

One of the points on the list is about SSL certificates. All connections must be secure ie use SSL/HTTPS. you can't use self signed certificates and they must be from a trusted source. Amazon points to a list maintained by Mozilla. Fortunately the organisation that Internet-radio uses seems to be on the list

Bye for now
 
Top