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:
To visit Icecast over https://, 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 for Apache. Once it works, you can pass the traffic to Icecast2.
Browser
│
│ https://example.com/radio.mp3
▼
┌───────────┐
│ │
│ Apache │:443
│ │
└┬──────────┘
│
│ http://localhost:8080/radio.mp3
▼
┌───────────┐
│ │
│ Icecast │:8080
│ │
└───────────┘
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:
#
# Apache VirtualHost serving my Icecast under HTTPs (:443)
#
# This frontend webserver passes all the traffic to
# the underlying Icecast, listening on port 8000.
#
# The certificate comes from Let's Encrypt.
#
# Credits: https://stackoverflow.com/a/71383133/3451846
<virtualhost *:443>
ServerName example.com
# this path is not useful and it's 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.
WoW64 - aka Windows (32-bit) on Windows (64-bit) - is a subsystem that enables 32-bit Windows applications to run on 64-bit Windows. Most people today are familiar with WoW64 on Windows x64, where they can run x86 applications. WoW64 has been with us since Windows XP, and x64 wasn’t the only architecture where WoW64 has been available - it was available on IA-64 architecture as well, where WoW64 has been responsible for emulating x86. Newly, WoW64 is also available on ARM64, enabling emulation of both x86 and ARM32 appllications.
Some malware samples are known to do various checks to determine if they are running in a virtual machine. One of the common checks is to look for the presence of certain hardware components that are typically not emulated in virtualized environments. One such component is the CPU fan.
The main purpose of my Raspberry Pi is to act as a central music box. This task can easily be solved with MPD and Icecast2. Read on and get it working within...