Icecast 2 and SSL
For the Icecast2 complete certificate, you can use the command:
cat /etc/letsencrypt/live/domain.com/fullcert.pem /etc/letsencrypt/live/domain.com/privkey.pem > /etc/icecast2/bundle.pem
This will concatenate and save both certificates to a single file called bundle.pem under icecast2 folder, to which you can point the icecast2 configuration.
I have also found this very helpful and complete guide for reference: https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
Add HTTPS support to Icecast2 using Let's Encrypt
Do you have native SSL support in your icecast2 package?
If you love to use the official package, first check if you have SSL support in your already installed icecast2
package:
ldd /usr/bin/icecast2 | grep ssl
If you don't see anything, you have no native support for SSL. In this case you can choose one of these options:
A
: remove the package and install something elseB
: setup a frontend webserver using nginxC
: setup a frontend webserver using Apache (← this answer)
How to use Apache to setup a frontend webserver with HTTPs support, and serve Icecast2
If you would like to give https://
support to Icecast, you can install Apache and use it as frontend webserver, listening on standard port 443. It's easy to use Let's Encrypt to create a free certificate. Once it works, you can pass the traffic to Icecast2.
If you use Debian GNU/Linux, here the guide:
- https://wiki.debian.org/Icecast2
The core of the solution is to enable an apache VirtualHost like this:
<virtualhost *:443>
ServerName example.com
# this path is unuseful and used only for Let's Encrypt's temporary files during the renewal process
DocumentRoot /var/www/html
# send all traffic to Icecast in plaintext
<Location "/">
ProxyPass http://localhost:8000/
ProxyPassReverse http://localhost:8000/
</Location>
# these files are served from /var/www/html to serve Let's Encrypt temporary files
<Location "/.well-known/acme-challenge">
ProxyPass !
</Location>
<IfFile /etc/letsencrypt/live/example.com/cert.pem>
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem
</IfFile>
</virtualhost>
<VirtualHost *:80>
ServerName example.com
Redirect / https://example.com/
</VirtualHost>
And then enable it and issue your certificate:
letsencrypt certonly --domain example.com --webroot --webroot-path /var/www/html
But this is explained maybe better from the above guide.
At the moment the guide does not cover nginx
but other answers might give a similar practical example using that technology as well as apache2
. The benefit of involving a frontend webserver like apache2
or nginx
is that you don't have to touch Icecast. Also, it allows to serve Icecast2 among your already-existing websites, if any.
Other answers might want to talk about an Icecast2's native interface with Let's Encrypt. At the moment I can share just the apache2
method that is the one I use in production since years without any problem. Moreover since I use Debian GNU/Linux, my package has not SSL support.
does icecast force ssl if enabled?
However this wording is unclear to me whether or not the ssl is forced for this port or not?
On that particular socket, it is. A server bound to that socket cannot support HTTPS and non-HTTPS at the same time. Usually, you'll use port 80
for HTTP and port 443
for HTTPS.
Note that you can have multiple sockets bound to Icecast, simply by putting in multiple <listen-socket>
sections. It's common to serve both HTTP and HTTPS this way.
I am wondering this because we are running into an issue where safari is forcing ssl redirect
Your server configuration is irrelevant here. Icecast will not redirect HTTP requests to HTTPS. It's possible that you hit the stream on HTTPS once and that Safari cached this. It's also possible that you turned on HSTS or something for your domain. You would have to debug this with a tool like Fiddler.
and we want to keep the server listening on both ssl and non-ssl on the same port
You say "keep the server listening"... that's not possible. If it appears you're set up this way today, that's not accurate.
IceCast SSL certificate as not secure
You've got a self-signed certificate that is not contained in any trustchain. Hence, it is marked as insecure by your browser.
There is hardly any way to fix this with your existing certificate. You can try through the Let's Encrypt initiative.
Relaying a HTTPS stream with Icecast2
A good workaround for this problem is to set up a reverse proxy using nginx. I did this to access a https stream over http and icecast2 is able to relay it without issues.
Related Topics
How to Make the Watch Command Interpret Vt100 Sequences
Converting a Pcap Trace to Netflow Format
Core Dump Filename Gets Thread Name Instead of Executable Name with Core_Pattern %E.%P.Core
Pkill Returns 255 in Combination with Another Command via Remote Ssh
Provide Password Using Shell Script
How to Find Out Where Is My Code Causing Glib-Gobject-Critical
How to Execute Multiple Commands After Sudo Command
Subprocess Library Won't Execute Compgen
Nasm Print One Character at a Time
Sshpass: Command Not Found Error
How to Install Valgrind Properly
How to Use a Seq_File in Linux Kernel Modules
Difference Between Kernel, Kernel-Thread and User-Thread
Explanation of Memcpy Memmove Glibc_2.14/2.2.5
How to Set Runpath of a Binary
Fatal: Git Was Built Without Support for Git-Add--Interactive (No_Perl=1)