Updated: 8 October 2026 · Applies to: Shoutcast DNAS 2.6.1.777 and nginx 1.26.3 on Debian 13.7, tested; Centova Cast 3.3.4, from Centova documentation
A website served over HTTPS cannot play a radio stream from a plain http:// address: browsers block it as mixed content, so your player needs an https:// stream link. Choose by where the stream runs:
- On Centova Cast: use its stream proxy (option 1).
- Your own Shoutcast DNAS 2.6.1: add
sslCertificateFileandsslCertificateKeyFiletosc_serv.conf(option 2). In our test this served HTTPS with no licence key. - You want port 443, already run nginx or also serve Icecast: an nginx reverse proxy (option 3).
- You can only change your website: a PHP proxy (option 4), for small stations.
1. Centova Cast stream proxy
Since version 3.2.14 (the current release is 3.3.4), Centova Cast includes a stream proxy that serves tune-in links on ports 80 and 443 with a Let’s Encrypt certificate. The administrator runs /usr/local/centovacast/sbin/set_secure --fqdn=radio.example.com --email=you@example.com and allows the proxy per account on the Limits tab; the https links then appear on the stream’s Quick Links page. Ports 80 and 443 must be free on that IP address. Steps: enable the Centova Cast stream proxy; background: does Centova Cast include a proxy for HTTPS.
Centova also offers native TLS per station (Allow native TLS for the admin, then Enable native TLS, certificate chain, private key and Test TLS for the station), but recommends the stream proxy. According to Centova, Shoutcast stations need DNAS 2.6.1 for native TLS, because 2.6.0 required a premium licence key that can no longer be obtained.
2. Shoutcast DNAS 2.6.1 native SSL
The DNAS manual still describes these settings as “for unlocking Premium https stream support”, while Centova says 2.6.1 enables premium features without a licence key. We tested DNAS 2.6.1.777 for Linux (sc_serv2_linux_x64-latest from download.nullsoft.com) with these two lines in sc_serv.conf and no userid or licenceid:
sslCertificateFile=/opt/dnas/ssl/fullchain.pem sslCertificateKeyFile=/opt/dnas/ssl/privkey.pem
The log showed (timestamps removed):
INFO [MAIN] Shoutcast DNAS/posix(linux x64) v2.6.1.777 (Jan 28 2022) ... INFO [MAIN] SSL keys installed INFO [MAIN] Starting 2 network threads INFO [MICROSERVER] Listening for source and client connections on port 8000
With a source connected, the stream played over HTTPS on the normal port (-k because our test certificate was self-signed):
$ curl -sS -k -D - -o /dev/null --max-time 4 https://127.0.0.1:8000/stream HTTP/1.0 200 OK ... icy-br:128 content-type:audio/mpeg ... curl: (28) Operation timed out after 4000 milliseconds with 157153 bytes received
(A live stream never ends, so curl stops at its limit.) We also found:
- No log line mentioned a licence or Premium, and HTTPS still worked when we checked again after the DNAS had run for 30 minutes.
- Plain
http://links keep working on the same port. - Without the two lines, the HTTPS request failed:
curl: (35) Send failure: Broken pipe. - Use the full chain. With only the server certificate in the file, a verifying client failed with “unable to get local issuer certificate”; with the intermediate added, it connected.
- After we replaced the certificate files, the DNAS kept serving the old certificate until it was restarted. Restart it after every renewal, for example from a Certbot
--deploy-hook. - The DNAS uses its built-in OpenSSL 1.1.0e and offered TLS 1.2 only; a client limited to TLS 1.3 could not connect.
Listeners then use https://radio.example.com:8000/stream (your host name, port and stream path).
3. nginx reverse proxy
nginx handles HTTPS on port 443 and passes listeners to the DNAS (or Icecast) on its local port. Your encoder still connects to the streaming server directly. Tested with nginx 1.26.3, in /etc/nginx/conf.d/radio.conf:
server {
listen 443 ssl;
server_name radio.example.com;
ssl_certificate /etc/letsencrypt/live/radio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/radio.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_buffering off;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
$ nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Then run systemctl reload nginx. With buffering off, nginx passes the audio on as it arrives, according to nginx. Through the proxy our stream returned HTTP/1.1 200 OK with Content-Type: audio/mpeg.
The DNAS takes the listener’s address from the first entry of the X-Forwarded-For header (its log marks these lines (xff)). With the common $proxy_add_x_forwarded_for, a listener who sent a made-up header was logged under the made-up address; with $remote_addr, as above, the DNAS logged the real one. It also trusts the header from clients that connect to port 8000 directly.
With SELinux (AlmaLinux, Rocky Linux, RHEL): in the AlmaLinux 10.2 policy we checked, port 8000 is labelled soundd_port_t, and nginx may only connect to it with setsebool -P httpd_can_network_connect 1.
4. PHP proxy on your website
A script on your HTTPS website fetches the stream and passes it on. Each listener keeps one PHP worker busy, so it only suits a few listeners. The tested script and its limits: PHP proxy to re-stream a radio stream on HTTPS.
Streams hosted with Ucartz
On Shoutcast and Icecast hosting or a Shoutcast reseller account, open a support ticket and ask for proxy access on your stream for an https link. On a Centova Cast dedicated server, run the commands above as root or open a ticket for help.
Official documentation: Centova: mixed content warnings and native TLS, Centova stream proxy, nginx proxy module and the Shoutcast DNAS Server documentation included in the DNAS download.
