Putting VICIdial behind HTTPS

Running VICIdial over plain HTTP works on day one, then quietly causes problems on day two: passwords travel in the clear, and the in-browser softphone refuses to connect. Putting the whole thing behind HTTPS fixes both. This post covers why TLS matters here, how to get a certificate, the websocket gotcha that surprises almost everyone, and how to redirect plain traffic to the secure site.

Why the screens need TLS

Agents and managers log into VICIdial with usernames and passwords, all day, from wherever they happen to be. Without TLS those credentials cross the network unencrypted, which is a problem on any shared or public connection. TLS is the encryption layer that turns http into https and protects everything in transit. For a dialer that handles customer phone numbers and call recordings, encrypting the web interface is a baseline, not a nice-to-have.

Getting a certificate

A certificate proves your server really is the domain it claims to be, and lets browsers trust it without warnings. The easiest path is a free certificate from a public authority like Let's Encrypt, issued against a real domain name pointed at your server. A self-signed certificate technically encrypts traffic, but browsers throw scary warnings and, more importantly, the webphone will reject it. Use a properly issued cert tied to a real hostname.

This is much easier when the server has its own clean hostname. A Branded subdomain such as dialer.yourcompany.com gives you a stable name to issue the certificate against and to hand to agents, instead of a bare IP address that no certificate authority will sign.

The websocket gotcha

The browser-based Webphone makes calls using WebRTC, which carries its signaling over a secure websocket. Browsers only allow a secure websocket from a page that itself loaded over HTTPS with a valid certificate. So if your certificate is missing, self-signed, or expired, the agent screen may load but the phone will silently fail to register. The audio side rides on RTP just as a regular SIP call does, and modern setups encrypt that media with SRTP so the voice stream is protected too. If you also terminate signaling over SIP over TLS, the entire path from browser to server is encrypted end to end.

How a request reaches the secure site

flowchart LR
  A[Agent browser] --> B{Request port 80 or 443}
  B -- port 80 --> C[Redirect to HTTPS]
  C --> D[Secure site on 443]
  B -- port 443 --> D
  D --> E[Valid certificate check]
  E --> F[Agent screen loads]
  F --> G[Webphone opens secure websocket]

Redirect basics

Once HTTPS works, send all plain HTTP traffic to it. In your web server config, add a rule on port 80 that issues a permanent redirect to the same path on port 443. That way an agent who types the bare address, or clicks an old bookmark, still lands on the encrypted site instead of the insecure one. Test it by visiting the http address and confirming the browser bar flips to https.

One caution worth repeating: certificates expire. Set up automatic renewal when you first issue the certificate, because an expired cert breaks the webphone for every agent at once, usually on a morning when you are not watching.

Where this fits

HTTPS is part of finishing a clean install, alongside the firewall and the post-install checks. See our complete guide to installing VICIdial for the full sequence, and the related piece on which ports to open for VICIdial for the networking side that has to line up with your certificate.

Issuing, installing, and auto-renewing a certificate, then wiring it to the webphone, is a moving target you have to maintain forever. VICIfast hands every customer a server already on a branded subdomain with a valid, auto-renewing certificate, provisioned in under 40 seconds. See VICIfast pricing if you would rather not manage TLS yourself.