Revoke a certificate on your internal certificate authority, publish the new revocation list, and Chrome will carry on accepting the certificate. According to the US Defense Department's Chrome security checklist, if the online-checking policy "is not set, or is set to false, then Chrome will not perform online revocation checks." Most of the revocation machinery a textbook PKI describes is never consulted by the clients that matter most in a video estate.
Our post on air-gapped video covers why an isolated network needs one at all: browsers only open cameras on secure pages, and no public CA will vouch for an internal hostname. This post is the operating manual. It covers which endpoints need the CA, how to get its root onto every device, which certificates the platforms will accept, and why rotation does the job revocation was supposed to do.
What in a Video Estate Actually Needs the Internal Certificate Authority
Start by scoping the CA to the endpoints that need it. Fewer certificates means fewer expiry dates, and one category of certificate in a video system never needed a CA at all.
Endpoint | Needs the CA? | Why |
|---|---|---|
Web app and signalling (HTTPS, WSS) | Yes | Browsers require a trusted certificate before they expose the camera |
TURN over TLS | Yes | Clients validate the relay's certificate like any TLS server |
Media between client and SFU (DTLS-SRTP) | No | Self-signed certificates, verified by a fingerprint carried in signalling |
Recording uploads, webhooks, internal APIs | Yes | Service-to-service TLS; optionally mutual TLS |
Native mobile and desktop apps | Yes, with extra work | Each platform decides separately whether to trust a private root |
Most of these sit at the network edge of a self-hosted deployment, and the relay is the one teams forget. Clients on restrictive networks fall back to TURN over TLS on port 443, and that connection fails silently if the relay's certificate comes from a root the client doesn't trust. The calls that break are exactly the ones on the most locked-down networks.
The media row is the one that saves work. RFC 5763, which defines how DTLS-SRTP keys are set up, says the certificates "can be self-signed and completely self-generated." The binding comes from a fingerprint of that certificate sent in the SDP. Browsers already generate their own, and media servers can too. Leave media certificates out of the CA's scope.
That has a consequence worth stating. The fingerprint travels over signalling, so the TLS certificate on your signalling endpoint is what stops someone substituting their own DTLS certificate in the middle. The CA doesn't encrypt the media, but it protects the channel that vouches for the media's keys.
The Root: Offline, Constrained and Distributed
A sound shape for a video estate is two tiers. The root signs an issuing intermediate and is then switched off and stored offline. The intermediate does the daily issuing. If the intermediate is compromised you revoke and replace it with the root, which nobody could reach.
Constrain the intermediate to your own names. RFC 5280 defines a name constraints extension that limits which hostnames a CA may issue for, and requires conforming software to recognise it. Put the constraint on the intermediate as well as, or instead of, the root: enforcement of constraints placed on a root has varied, and independent testing found that Chrome only began enforcing root name constraints in version 112 in 2023. With a constrained intermediate, a leaked issuing key can only mint certificates for names under video.corp.example.
Distribution is where the hours go, because every platform has its own trust store and its own rules.
Platform | How a private root becomes trusted | The catch |
|---|---|---|
Windows | Group Policy or MDM into the machine store | Chrome and Edge read it; per the Chrome Root Store FAQ they consider local trust for TCP-based TLS |
macOS | Configuration profile into the System keychain, set to Always Trust | Same FAQ: trust is read from the keychain's SSL setting |
iOS and iPadOS | MDM or Configurator profile | Manually installed profiles are not trusted for TLS until the user enables them under Certificate Trust Settings, per Apple's guidance |
Android | Device policy or user install | Apps targeting API level 24 or later ignore user-added CAs unless their network security config opts in, as the Android team announced in 2016 |
Firefox | Enterprise roots from the OS store, or the ImportEnterpriseRoots policy | On Linux it needs its own import, per Mozilla's CA guide |
The Android row matters most if you ship a native app. A browser on the device may trust your root while your own app, built against a modern SDK, rejects the same server. The fix belongs in your app's network security config, so it ships with every build of the app.
Leaf Certificates the Platforms Will Accept
Apple publishes explicit requirements, and they apply to all TLS server certificates on iOS 13, macOS 10.15 and later, with no exception carved out for private CAs:
- RSA keys of at least 2,048 bits, and SHA-2 signatures.
- Hostnames in the Subject Alternative Name. Names in the Common Name are no longer trusted.
- For certificates issued after 1 July 2019, the serverAuth extended key usage, and a validity period of 825 days or fewer.
Internal CAs that issue five-year certificates, a common default in older templates, produce certificates that iPhones and Macs refuse. Build your issuing templates to Apple's rules from the start, so no certificate has to be reissued when the first iPhone joins.
Rotation Is the Control That Works
Revocation is a list of certificates to stop trusting. Expiry stops trusting a certificate without anyone needing to check a list. That is why the stronger design for an internal CA leans on short lifetimes and automated renewal.
step-ca, an open-source CA, issues 24-hour certificates by default and renews them when about two-thirds of the lifetime has passed, retrying every minute if renewal fails. Its documentation calls short lifetimes "passive revocation." A stolen 24-hour certificate is useless by tomorrow, whether or not any client checks a list. It also supports ACME, the protocol public CAs use for automated issuance, so the same tooling that renews public certificates can renew internal ones.
For an isolated network this settles a real tension. Short lifetimes are only safe if renewal never depends on reaching outside, so the CA and its ACME endpoint must sit inside the boundary along with everything else. Once they do, renewal is routine and expiry stops being a scheduled outage.
Three rotations need planning beyond the leaves:
- Intermediate. Issue the new intermediate from the root while the old one is still valid, deploy the new chain to servers, then let the old intermediate's leaves age out. With 24-hour leaves that takes a day.
- Root. Distribute the new root to every device well before anything chains to it. This is the slow one, because it runs at the speed of your MDM and your least-managed device.
- Server reload. Check that each component reloads a renewed certificate without a restart. A TURN server or media server that only reads its certificate at startup turns a routine renewal into a dropped call.
Short lifetimes have one gap. Renewal lets anyone holding a private key keep extending the certificate, so step-ca's documentation warns that a retired certificate still has to be explicitly revoked on the CA, to stop it renewing.
Revocation: What Actually Checks It
The opening line was not an exaggeration. Chromium-based browsers stopped making online OCSP and CRL checks for most certificates years ago; Microsoft Edge aligned with Chrome in 2018, as Eric Lawrence's account of Edge's revocation behaviour explains. What Chrome does check by default is CRLSet, a list Google pushes for publicly trusted CAs. A certificate from your internal CA will never be on it.
Online checks for private roots exist, but only by policy. Edge's RequireOnlineRevocationChecksForLocalAnchors policy makes it "always" check certificates from locally installed CAs, and its description says certificates whose status can't be fetched are treated as revoked. It is supported on Windows only. That is a defensible setting for a managed Windows fleet, and an outage risk if the CRL host ever goes down.
So publish a CRL, for the clients and services that do check it: your own backend services, recording and storage components, and anything you configure to verify. Point its distribution URL inside your network, which RFC 5280's CRL distribution points extension supports. Skip OCSP. The public ecosystem is retreating from it, and Let's Encrypt switched its OCSP responders off on 6 August 2025, citing privacy and the cost of running them. An internal responder is one more service to keep available, for clients that mostly won't ask it.
The practical order of defences is short lifetimes first, then an explicit revoke on the CA so the certificate can't renew, then a CRL for the components that read one.
Where the Internal Certificate Authority Stops and Media Keys Begin
The CA authenticates servers and protects the signalling that carries DTLS fingerprints. It doesn't make the media private from the media server, because every hop's encryption ends at the SFU. If the threat is the server operator, that is a separate layer with its own keys, covered in our post on end-to-end encryption for group video.
The Bottom Line
Scope the internal certificate authority to the endpoints that need it, keep the root offline and the intermediate constrained, and build leaf templates to Apple's rules. Then treat rotation as your main control, because the browsers your users run will not consult your revocation list unless you force them to.
What's Next
A CA that renews certificates every day needs someone watching when renewal fails. Next: what to alert on before a call goes bad on the server side of a video estate.
Frequently Asked Questions
Why do I need an internal certificate authority for self-hosted video?
Browsers only allow camera and microphone access on secure pages, so the web app and signalling endpoint need certificates the browser trusts. On an internal or isolated network no public CA will issue those, so an internal certificate authority issues them and its root is installed on every device.
Does WebRTC media need certificates from my CA?
No. DTLS-SRTP uses self-signed certificates, and RFC 5763 binds them with a fingerprint sent in the SDP. What the CA secures is the signalling channel that carries the fingerprint.
Does Chrome check my internal CA's revocation list?
Not by default. Chrome makes no online OCSP or CRL checks unless a policy enables them, and its built-in CRLSet only covers publicly trusted CAs. Short certificate lifetimes are the more reliable control.
How long should internal certificates last?
As short as your renewal automation can sustain. step-ca defaults to 24 hours and renews automatically, and Apple rejects any TLS server certificate valid for more than 825 days. Hours to days is a good target where renewal runs inside your network.
Why does my mobile app reject a certificate the phone's browser accepts?
On Android, apps targeting API level 24 or later don't trust user-added CAs unless their network security config opts in. On iOS, a manually installed root has to be enabled under Certificate Trust Settings; MDM-installed roots are trusted automatically.
Who owns the certificates in an on-premise video deployment?
You do, for every endpoint inside your network. With an on-premise deployment of a platform based on SFU architecture, such as Samvyo, the media servers, TURN relays and recording run on infrastructure you control, so their TLS certificates come from your CA and your renewal schedule.
