If you’ve been running internal dashboards on Screenly, you’ve probably bumped into the same problem everyone does eventually: the content that would actually be useful to display is sitting behind a private network.

Intranet pages, internal analytics, live data feeds from systems that were never meant to be public. Displaying that kind of content securely has always required some compromise. Either you expose more than you wanted to, or you keep the signage generic enough to avoid the problem entirely.

We recently added Tailscale support to help with the network access side of that problem. Once a player is on your Tailnet, it can reach internal URLs and private services without firewall rules or exposed endpoints.

But getting a player onto the right network is only part of the picture. The next question is: once it can reach your internal web server, how does the server know the request is actually coming from an authorized Screenly device and not something else that found its way onto the network?

That’s what mTLS solves. Starting with ScreenlyOS 26.2.0, Screenly players can now present a device certificate when loading web assets.

That means your web server can cryptographically verify that an incoming request is coming from a specific, authorized Screenly device and not just anyone who knows the URL.

What mTLS actually does here

Standard HTTPS is one-directional: the server proves its identity to the client.

Mutual TLS flips it around.

Both sides authenticate.

The client (in this case, your Screenly player) presents its own certificate during the TLS handshake, and the server decides whether to trust it.

For digital signage, this is a meaningful security improvement. Your internal dashboard URL stops being a secret that just hasn’t leaked yet, and becomes a resource that requires a valid device identity to access.

A browser pointed at the same URL, without the right certificate, gets rejected before it sees anything.

Each Screenly player has its own unique self-signed certificate. If you want your server to trust specific devices individually, you configure it to trust the certificates you’ve downloaded directly.

If you’d rather trust all Screenly players at once, or manage things at a higher level, you can use the Screenly CA instead. Your server trusts the CA, and any player certificate issued by it is automatically accepted.

You can also combine both approaches: CA-level trust for most assets, with individual certificate pinning for anything that needs tighter control.

How it works in practice

The setup happens in three places: the Screenly dashboard, your web asset settings, and your web server config.

On the Screenly side

Download the public certificate from each player you want to authorize. Each screen has its own .pem file, available from the screen’s Settings page under View Certificate. If you’re authorizing multiple players, you’ll need a certificate from each one.

On the asset side

Open the web page in your Content Library, go to Advanced, and toggle on Allow sending client certificate. That’s what tells the player to present its certificate when loading that specific asset. It’s off by default, so existing assets are unaffected until you explicitly enable it.

On the server side

Configure it to require client certificates and choose how to trust them. You have a few options.

Per-device trust

Download the .pem certificate from each player and point your server directly at those files. For multiple players, concatenate them into a single bundle. Only the specific devices you’ve added will get through.

Screenly CA trust

The Screenly CA certificate is available from any screen’s Settings page. Your server trusts it once, and every player certificate issued by it is automatically valid. Easier to maintain as your fleet grows.

Combined

Both can be combined: CA trust for broad access, individual certificates pinned where you need stricter control.

The major web servers (NGINX, Apache, HAProxy, Caddy) all support this natively. The support article has configuration examples for each of them.

If you’d rather not touch your web server config at all, you can offload the certificate verification to your CDN or edge provider. Cloudflare Access, AWS ALB, and similar infrastructure-level tools support mTLS and can handle the verification before traffic ever reaches your backend.

Automating certificate management with the API

Manually downloading and updating .pem files works fine for a handful of devices, but it doesn’t scale. If you’re running a larger fleet or want to keep your web server’s trust bundle in sync automatically, the Screenly API exposes everything you need.

You can pull the certificate for any screen programmatically, which makes it straightforward to build a script that fetches all device certificates and regenerates your server’s trust bundle whenever a screen is added or removed. The same approach works for deprovisioning: when a player is retired, remove its certificate from the bundle and reload your server config, without touching anything else.

This means certificate rotation and fleet changes don’t require manual steps on the server side. Your trust bundle stays current as your deployment changes.

Mixing mTLS with regular access

One scenario worth thinking through: what if the same dashboard needs to be accessible to both your Screenly players and regular employees using a browser?

The clean approach is to route them separately at the DNS level. Two subdomains, same backend: one configured for standard corporate auth, one requiring a client certificate.

Employees use one URL, signage players use the other. You get strict device verification on the signage path without breaking anything for people who need to view the same data in a browser.

If you need a single domain for both, optional mTLS is an option. The server accepts connections without a certificate but applies different routing based on whether a valid one was presented.

It’s a bit more configuration, but it works if subdomain splitting isn’t feasible.

A note on ScreenlyOS

mTLS certificate support requires ScreenlyOS 26.2.0 or newer.

ScreenlyOS is the operating system that runs on Screenly hardware players as well as DIY Raspberry Pi setups.

The device certificate lives at the OS level, which is what makes per-device identity work the way it does here.

Who this is for

If you’re in an environment where internal dashboards are the primary use case (manufacturing floors, NOCs, executive suites) and you’ve been relying on IP whitelisting or VPN workarounds to get signage access to private content, this is a cleaner path.

Pair it with Tailscale and you have the full picture: players that can reach your private network, presenting device certificates that your server can verify. Network access and application-level identity, both handled.

The device identity is built in, it’s per-player, and it doesn’t require any special network topology.

It’s supported on Screenly Player, Screenly Player Max, Raspberry Pi 4, and Raspberry Pi 5. The full setup guide is in the support documentation.