Is there any way to get Shoutcast to run over HTTPS, using some sort of proxy?
Will the built in Centova proxy work for this?
Thanks.

It should be possible to run the DNAS behind something like an nginx proxy or equivalent to get it acting like it's coming over HTTPS. but I cannot remember if there were any obvious issues with doing this from those who I've had tell me that's what they were doing (is only possibly something to do with admin access that might go a bit funky depending on what is done to the headers passed through the proxy). Is a shame the DNAS doesn't just do it natively *shrugs*

-dro

I got it working by using stunnel on the server itself to relay the Shoutcast instance over a HTTPS port.

Used this guide, though I may have had to change a few things: https://www.interserver.net/tips/kb/using-stunnel-to-add-ssl-to-shoutcast-or-any-service-that-does-not-have-ssl/

Just was wondering if the built in proxy did something like that as well, instead of needing to use stunnel.

The only annoying part with using stunnel is that any connections going through there show up in the admin panel as coming from the server itself, and not the actual originating IP, which I guess makes sense, just is annoying.

Wish there was a better way of doing it...

Thanks for sharing this, guys. I know the thread has been dead a long time, but I found it and it helped me solve the same problem. For future generations, I shared this as an AWS image. To use it:

- create a free Amazon Web Services account
- create an instance (I used free tier) of ami-947151f1
- open ports 80 and 443 on your security group
- use the certbot certonly command described here (https://certbot.eff.org/#ubuntutzesty-other)  to get a free SSL certificate from letscertify
- edit /etc/stunnel/stunnel.conf to point to your new certificates and the feed you want to proxy (directions in the config file)
- reboot or restart stunnel

thanks to the original authors of this thread!

The only annoying part with using stunnel is that any connections going through there show up in the admin panel as coming from the server itself, and not the actual originating IP, which I guess makes sense, just is annoying.

Have any one figure out how to solve this problem? or another alternative where centova cast can see all the listeners ip and locations individually? will help for royalty fees purpose.

I need to refresh this a bit as I had working stunnel with ShoutCast until newer version of ShoutCast...

It is still fully working for me on version 2.5.1.724 and old 2.4.7.256.

On version 2.5.5.732 and 2.5.5.733 I can access stream on stunnel using IP address but not domain name, so https://1.2.3.4:8000 works but https://example.com:8000 doesn't.

In older versions I remember I had to set srcip and dstip to "any" to get it to work but it looks like right this setting doesn't affect anything.

Any ideas ?

I found lots of unanswered or partially answered posts regarding this so I decided to share my experience, as it's actually pretty easy to do.

Depending on your server setup you may have to tweak some aspects, but here's my configuration.

I'm running two separate VPS instances hosted on Linode, both are the cheapest $5/month packages running Ubuntu 16.04. I got my SSL certificate for free from Certbot using their Nginx CLI plugin. For the purpose of this guide I'm assuming an SSL certificate is already set up properly and serving encrypted traffic to requests on port 443.

My first server is running a LEMP stack (installed using EasyEngine) and hosts the website for our station, the domain name is pointed at this server. The second server is running Centova Cast installed with Shoutcast v2 and LiquidSoap. As both servers are deployed in the same location Linode offer (at no cost) the option to obtain local IP addresses for both machines and network them locally within their data centre, which I have done.

On the second server I have enabled the option within Centova to proxy the streams onto port 80. You can set this all up on a single server without doing this if you only have one server to play with, but if you have two then this makes things really easy. Once you have followed the instructions to enable the proxy on port 80 then your second server is almost ready to go.

On the first server your Nginx install needs to have been built with the "--with-http_realip_module" enabled, if you install using EasyEngine then this will already be done for you. It will work without this, but you will have the issues others have reported with the listener stats always showing the IP address of your proxy server instead of the actual listeners IP.

The Centova proxy setup uses variables in the proxy URL to allow you to access any stream you like via the proxy. I only needed a 128 and 320 stream so I changed the settings in the default Centova Nginx config files to suit, but if you look at the originals it's fairly straightforward to figure out if you have an understanding of Nginx, and will only take you 20 minutes of reading Nginx instructions if you dont.

Anyway, in the second server the Nginx location config looks similar to this once you enable the Port 80 proxying option in Centova:

location = /128/ {
    proxy_pass                      http://127.0.0.1:2198/proxy-redirect/ACCOUNT-USERNAME;
    proxy_set_header                X-MountPoint /stream128;
    proxy_redirect                  off;
    proxy_connect_timeout           8;
    proxy_read_timeout              15;
    proxy_send_timeout              15;
    proxy_max_temp_file_size        0;
}

location ~ ^/streamproxy/(.*)$ {
    internal;
    set $stream_url http://$1;
    proxy_buffering                 off;
    proxy_ignore_client_abort       off;
    proxy_intercept_errors          off;
    proxy_next_upstream             error timeout invalid_header;
    proxy_redirect                  off;
    proxy_set_header                User-Agent "$http_user_agent [ip:$remote_addr]";
    proxy_set_header                X-Forwarded-For $remote_addr;
    proxy_connect_timeout           8;
    proxy_send_timeout              60;
    proxy_read_timeout              60;
    proxy_max_temp_file_size        0;
    proxy_pass                      $stream_url;
}

You will find this file at /usr/local/centovacast/etc/web.d/cc-proxy.conf
Edit this file, and inside the server block but before the location blocks you need to add this, replacing PROXY_IP_HERE with the local IP address of server 1:

    set_real_ip_from PROXY-IP-HERE;
    real_ip_header X-Real-IP;
    real_ip_recursive on;

This MUST be outside all of the location blocks. The first line tells server 2 that server 1 is a trusted source for setting the original IP of the visitor, the next two lines provide the header containing the real IP and the method of replacement to use.

Then in server 1 the Nginx config for your site (in /etc/nginx/sites-available/) needs to contain a location block that looks something like this:

location = /streams/128/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Host $remote_addr;
    proxy_set_header Pragma no-cache;
    proxy_set_header Cache-Control no-cache;
    proxy_set_header Accept-Encoding */*;
    proxy_set_header Accept */*;
    proxy_buffering off;
    tcp_nodelay on;
    proxy_pass http://SECOND_SERVER_IP:80/128/;
}

This is just a basic example, obviously you can add several of these, or use wildcard location matching etc to enable multiple streams or whatever you need to do.

In this example I'm telling server 1 to proxy any requests to https://www.mydomain.com/streams/128/ to http://SECOND_SERVER_LOCAL_IP/128/ on port 80 over the local network, while setting some custom headers to forward the real IP of the listener.

That's it. Save your changes, run the Centova fix permissions tool if necessary, restart Nginx on server 1 (nginx -s reload) and reload Centova on server 2 ( /usr/local/centovacast/centovacast stop, /usr/local/centovacast/centovacast start) and you are done. https://www.mydomain.com/streams/128/ should now connect and stream via port 443, padlock in address bar, no mixed content warnings, no firewall issues due to non standard ports and correct listener stats within Centova.