Set up HTTPS on a streaming VPS by getting a free Let’s Encrypt certificate with certbot, then pointing your streaming engine at the certificate files — the exact steps differ by engine, since NGINX-RTMP reads a PEM file directly while Wowza needs it converted into a Java keystore first. Skip this and your HLS or WebRTC stream will silently fail to play on any page served over HTTPS, because browsers block mixed content and refuse camera/mic access outside a secure context. It takes about 15 minutes per engine once you’ve done it once.
Key Takeaways
- HTTPS is not optional cosmetics for a streaming server in 2026 — Chrome, Safari, and Firefox block HTTP video from loading on an HTTPS page (mixed content) and require a secure context for WebRTC’s
getUserMedia(). - A free Let’s Encrypt certificate via certbot is what most production streaming VPS setups use; NGINX-RTMP consumes it directly, but Wowza requires converting the PEM files into a
.jkskeystore withkeytool. - Each engine has its own default HTTPS port: NGINX is usually put on 443, Ant Media Server defaults to 5443, MistServer defaults to 4433, and Wowza’s manager HTTPS port defaults to 8090 (stream ports are whatever you assign in
VHost.xml). - Certificate renewal is the part that actually breaks in production — use
certbot --webrootinstead of--standaloneso renewal doesn’t require stopping your live streaming server every 60–90 days. - HTTPS secures playback (HLS/DASH) and WebRTC signaling; it does not encrypt an RTMP push from an encoder. That’s a separate protocol, RTMPS, covered in our RTMPS vs RTMP guide.
Why Does a Live Streaming Server Need HTTPS in 2026?
Because the browser, not your server, decides whether the stream plays. If your site loads over https:// and your HLS manifest or WebRTC connection is served over plain http://, Chrome and Safari classify it as mixed content and refuse to load it — the video element just sits there with no error a typical viewer can diagnose. WebRTC compounds this: navigator.mediaDevices.getUserMedia() (used for browser-based publishing into Ant Media or WHIP endpoints) is flatly disabled outside a secure context, with localhost as the sole HTTP exception.
We see this constantly in support tickets that start with “the video just shows a spinner” — nine times out of ten, the embed page is HTTPS and the stream URL is HTTP. It’s an easy trap because RTMP ingest, HLS playback over plain HTTP, and browser testing on localhost all work fine individually; the failure only shows up once you deploy behind a real domain with HTTPS enforced.
How Do You Get a Free SSL Certificate for a Streaming VPS?
Let’s Encrypt via certbot is the standard path and it’s what we provision by default on managed StreamingVPS.com instances. On Ubuntu 22.04/24.04:
sudo apt install certbot python3-certbot-nginx -y
sudo certbot certonly --webroot -w /var/www/html -d live.example.comUse --webroot, not --standalone, on a live streaming box. --standalone binds its own listener to port 80, which means stopping NGINX (and dropping any active HLS delivery on port 80) every time the cert renews. --webroot just drops a validation file into a directory NGINX is already serving, so renewal is a no-op for your running stream. On a 2 vCPU / 4 GB test VPS, a first-time HTTP-01 challenge and certificate issuance took about 18 seconds end-to-end; renewal (certbot renew) runs from a systemd timer twice a day and only actually replaces certificates in the last 30 days of their 90-day validity window, so it’s not doing meaningful work most of the time it fires.
The certificate lands in /etc/letsencrypt/live/live.example.com/ as fullchain.pem and privkey.pem. What you do with those two files depends entirely on which engine you’re pointing them at.
How to Enable HTTPS on Each Streaming Engine
NGINX-RTMP reads the PEM files directly — no conversion needed. Add an HTTPS server block alongside your existing HLS location:
server {
listen 443 ssl;
server_name live.example.com;
ssl_certificate /etc/letsencrypt/live/live.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/live.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
location /hls {
types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; }
root /tmp;
add_header Cache-Control no-cache;
}
}nginx -s reload picks up the new config without dropping in-flight HLS segment requests, as long as you don’t time it mid-restart of the RTMP worker itself. RTMP ingest on port 1935 is untouched by this — this block only affects HLS/DASH delivery over HTTP(S).
Wowza Streaming Engine doesn’t consume PEM files — it wants a Java KeyStore (.jks). Convert with openssl and keytool:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem \
-out live.example.com.p12 -name wowza
keytool -importkeystore -deststorepass changeit -destkeypass changeit \
-destkeystore live.example.com.jks -srckeystore live.example.com.p12 \
-srcstoretype PKCS12Drop the resulting .jks into [install-dir]/conf/, then reference it in VHost.xml‘s <HostPort> block for the secure port via KeyStorePath (Wowza expects the keystore under the VHost config conf directory, e.g. live.example.com.jks), KeyStorePassword, and SSLConfig. Separately, the Wowza Streaming Engine Manager admin UI has its own HTTPS toggle in manager/conf/tomcat.properties (httpsPort=8090 by default) — that’s for admin access, not stream delivery, and it’s easy to confuse the two. Wowza also sells its own StreamLock certificates if you’d rather not manage renewal yourself, but Let’s Encrypt works identically once converted.
Ant Media Server has the smoothest path of the four: it ships a script that handles the whole certbot dance for you.
cd /usr/local/antmedia
sudo ./enable_ssl.sh -d live.example.comThis requires port 80 to be free for the HTTP-01 challenge and your DNS A record already pointing at the VPS. After it completes, Ant Media serves HTTPS on port 5443 by default, which also unlocks browser-based WebRTC publishing and playback — without it, WebRTC simply won’t initialize in the browser due to the secure-context requirement mentioned earlier. Version 2.6.2+ also exposes an equivalent toggle under Settings > SSL in the web panel if you’d rather not touch the command line.
MistServer takes a middle path: since v2.17 it includes a bundled tool, MistUtilCertbot, that automates Let’s Encrypt issuance for you, or you can point it at existing PEM files manually through the HTTPS output configuration. Its default HTTPS port is 4433, chosen deliberately so MistServer can run alongside another web server on the same VPS without a port conflict.
| Engine | Default HTTPS port | Certificate format | Renewal automation |
|---|---|---|---|
| NGINX-RTMP | 443 (you choose) | PEM (direct) | certbot renew via systemd timer |
| Wowza Streaming Engine | 8090 (manager); stream port is custom | JKS (converted from PEM) | Manual re-conversion needed on renewal, or StreamLock service |
| Ant Media Server | 5443 | PEM (handled by script) | Built into enable_ssl.sh / web panel |
| MistServer | 4433 | PEM (direct or via MistUtilCertbot) | Automated via MistUtilCertbot |
Does RTMP Ingest Need Encryption Too?
Not for the same reasons. Everything above secures delivery to viewers — HLS manifests, DASH segments, WebRTC signaling and media. It does nothing for the RTMP push from OBS, vMix, or a hardware encoder into your server on port 1935, which travels in plaintext by default. If your ingest stream key or content itself needs to be encrypted in transit — for example, a corporate customer streaming over an untrusted network — that’s RTMPS (RTMP over TLS), a separate setup with its own port and, for NGINX-RTMP specifically, its own workaround since the module has no built-in TLS termination and needs stunnel or a TLS-terminating proxy in front of it. We cover that configuration in detail in our RTMPS vs RTMP guide — treat HTTPS and RTMPS as two separate checkboxes, not one.
What Breaks When HTTPS Is Missing or Misconfigured?
Three failure modes account for most of the HTTPS-related tickets we see. First, mixed content blocking: an HTTPS embed page pointed at an http:// .m3u8 URL, which fails silently in the video element with no console error a non-developer would notice. Second, renewal breakage: a --standalone certbot setup that worked fine at issuance time, then quietly started failing every 90 days because port 80 was occupied by the running stream server at renewal time, and nobody noticed until viewers started reporting certificate warnings. Third, keystore drift on Wowza specifically — the PEM-to-JKS conversion isn’t automatic, so a renewed Let’s Encrypt certificate doesn’t propagate to Wowza until someone re-runs the openssl/keytool steps and restarts the engine; on a 90-day renewal cycle, this is exactly the kind of manual step that gets forgotten.
None of these are hard problems, but they’re the difference between “HTTPS enabled once, on launch day” and “HTTPS that’s still valid eight months later.” A cron job (or systemd timer, which certbot installs automatically) checking renewal status, plus a post-renewal hook that re-runs the JKS conversion for Wowza deployments, closes the gap.
FAQ
Does live streaming actually need HTTPS, or is plain HTTP fine for HLS playback?
It needs HTTPS in practice. Modern browsers block an HTTPS page from loading an HTTP video stream as mixed content, and Chrome, Safari, and Firefox all restrict autoplay and WebRTC camera/mic access to secure (HTTPS) contexts, so an HTTP-only HLS or WebRTC stream will silently fail to play on most sites today.
Can I use a free Let’s Encrypt certificate for a streaming VPS, or do I need a paid certificate?
A free Let’s Encrypt certificate works fine for HLS, DASH, and WebRTC delivery on NGINX-RTMP, Wowza, Ant Media, and MistServer, and is what most production streaming VPS setups use. A paid certificate only matters if you need extended validation branding or a wildcard cert from a specific CA for compliance reasons.
Does enabling HTTPS add noticeable latency to a live stream?
No. TLS handshake overhead adds a few milliseconds to the initial connection only, not to each segment or frame after that, and TLS 1.3 cuts the handshake to one round trip. On a properly sized VPS the CPU cost of TLS termination is negligible next to the cost of transcoding.
What port does each streaming engine use for HTTPS by default?
NGINX is commonly configured on 443, Wowza Streaming Engine Manager defaults to 8090 for its HTTPS admin port with stream delivery on whatever HostPort you assign a keystore to, Ant Media Server serves HTTPS on 5443 by default after running its SSL script, and MistServer’s default HTTPS output port is 4433.
Does RTMP ingest also need to be encrypted, or is HTTPS only for playback?
HTTPS secures HLS/DASH playback and WebRTC signaling; it does not encrypt an RTMP push from an encoder like OBS. If you need the ingest connection itself encrypted, that’s a separate protocol, RTMPS (RTMP over TLS), which most engines support alongside standard RTMP on a different port.
Get HTTPS Sorted Without the Manual Work
Every StreamingVPS.com plan ships with Wowza, NGINX RTMP, Ant Media, Red5, Flusonic, or MistServer pre-installed and live in 60 seconds — including HTTPS setup handled as part of managed provisioning, so you’re not hand-converting keystores or debugging certbot renewal hooks at 2 a.m. Get a pre-installed streaming VPS from StreamingVPS.com and go live securely today.
