Our audio streams were getting blocked by Chrome's insistence on https. Our initial workaround was to not use any javascript-based player, and instead just use a link to the stream URL with target = _blank to open it in a new window or tab. Now, working towards https support for our audio streams, we found two options.
1. Icecast 2.4.4 has support for SSL, but we need to recompile it on most platforms with the flag set as the icecast package which is available at this repo doesn't support SSL. ./configure --with-curl --with-openssl
2. The other option is to use an SSL reverse-proxy - Apache or Nginx.
Since we had Apache running on our server already, I tried the reverse-proxy method. I had to use acme.sh and not certbot since our server needs an OS upgrade. After the acme.sh installation, have to log out and log in (or open another shell) for the .bashrc changes to take effect. On the server, the main steps were:
a2enmod proxy
a2enmod proxy-http #(without this, got Internal Server Error)
service apache2 restart
a2ensite stream.ourdomain.tld
service apache2 reload
The file created for stream.ourdomain.tld in /etc/apache2/sites-available/stream.ourdomain.tld.conf was copied from another virtual host and then I added the lines like
ProxyPass /nameofstream http://11.22.33.44:8567/
ProxyPassReverse /nameofstream http://11.22.33.44:8567/
ProxyPass /nameofanotherstream http://11.22.33.44:8577/
ProxyPassReverse /nameofanotherstream http://11.22.33.44:8577/
</VirtualHost>
The file created for the ssl version had to be hand-written since acme.sh doesn't automatically create the config files unlike certbot. stream.ourdomain.tld-ssl.conf had the additional lines
<IfModule mod_ssl.c>
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/ssl/certs/stream.ourdomain.tld.cer
SSLCertificateKeyFile /etc/ssl/private/stream.ourdomain.tld.key
So, with acme.sh, first issued the certificate in Apache mode as root -
acme.sh --issue --apache -d stream.ourdomain.tld
and then installed it using
acme.sh --install-cert -d stream.ourdomain.tld \
--cert-file /etc/ssl/certs/stream.ourdomain.tld.cer \
--key-file /etc/ssl/private/stream.ourdomain.tld.key
a2ensite stream.ourdomain.tld-ssl
service apache2 reload
Worked.
Everything seems to be fine - Apache was not having any issues I could detect with top and a tail -f of the Apache access log. Cloudflare proxying had been turned on, but I'm not sure if it had any impact since this was a stream and not a static file which could have been cached.
CPU utilization and RAM utilization didn't change more than 1-2% - 97% idle CPU, and all the Apache processes together were using only 14% RAM or less of our 8 GB server, which didn't increase substantially from what it was before the test. Some 300+ clients connected via our website with the new links to the various streams in the last 90 minutes or so of the test.
Edit: See the later post, implemented with icecast-kh
https://hnsws.blogspot.com/2021/06/adding-ssl-https-to-http-mp3-streams.html