Firefox HSTS errors on Vimeo clear once the proxy CA is trusted

Firefox rejects the certificate presented for player.vimeo.com and, because the host sends HSTS, offers no exception button. Chrome on the same machines still plays some videos. The fault is a certificate-chain trust mismatch on the work network, not a browser version problem. The working fix is to get the certificate Firefox receives to chain to a root Firefox trusts: either deploy the network's TLS-inspection CA to Firefox, or exempt the video hosts from inspection.

Reading the symptoms as a trust-chain failure

Four observations decide the case. The error appears only at work. It started on one day after working the week before. It appears on both a desktop and a laptop. Other users on other networks load the same training pages without error. A fault that hits two independent machines on the same day and disappears off-site sits upstream of the PCs: a proxy, firewall, or DNS/security-policy change. A per-PC fault such as a stale profile or bad clock would not hit both machines together.

The remaining ambiguity is what "some videos" means. If the same embedded video fails in Firefox and plays in Chrome, the browsers differ in trust store. If different videos fail in the same browser, the network is treating different embed or CDN hostnames differently. Test one failing video in both browsers before changing anything.

Why HSTS removes the exception button and why Chrome differs

HSTS is a response header that tells the browser to reach the host only over HTTPS and to treat any certificate error as fatal. The browser caches that instruction per host. When validation fails, Firefox suppresses "Add Exception" because the host has declared that a user override is not permitted. The block is working as designed. It is reporting that the certificate it received does not validate.

A TLS-inspection appliance terminates the browser's TLS session, opens its own session to Vimeo, and presents a substitute certificate signed by the organisation's own CA. That substitute validates only in clients that trust the CA. Chrome on Windows validates against the operating-system certificate store, where IT normally pushes the inspection CA by group policy. Firefox by default validates against its own bundled store, so it does not see the CA and rejects the chain. The same mechanism explains partial failures: inspection rules are commonly scoped by URL category or hostname, so one embed host is decrypted and re-signed while another is passed through untouched.

Other causes produce the same page and are ruled out by the diagnostics: a system clock outside the certificate validity window, or a chain missing an intermediate. A clock fault would follow the individual PC. A network-side change on the day the fault began points at the appliance, either a new decryption policy or a renewed or replaced inspection CA that has not reached Firefox.

Capturing the certificate the network actually delivers

Identify the issuer from the affected machine on the work network. This separates an interception CA from a genuinely bad public certificate.

1. On the Firefox error page, open Advanced and record the error code and the certificate issuer shown.
2. From PowerShell on the same PC, read the certificate the network hands out:

   $tcp = New-Object Net.Sockets.TcpClient('player.vimeo.com',443)
   $ssl = New-Object Net.Security.SslStream($tcp.GetStream(),$false,{$true})
   $ssl.AuthenticateAsClient('player.vimeo.com')
   [Security.Cryptography.X509Certificates.X509Certificate2]$ssl.RemoteCertificate | Format-List Subject,Issuer,NotBefore,NotAfter

   The callback {$true} accepts any certificate so the script can display it. Use it only for reading, never for data transfer.
3. If OpenSSL is installed, openssl s_client -connect player.vimeo.com:443 -servername player.vimeo.com prints the full chain and the verify result.
4. Repeat step 2 for the hostname of a video that plays. Compare issuers. Different issuers for different hosts confirm selective inspection.
5. Check that the Windows clock falls inside NotBefore and NotAfter.

An issuer naming the organisation, its firewall vendor, or a security gateway means interception. A public CA issuer with a verify failure points to the clock, a missing intermediate, or a distrusted chain, and the fix moves to the certificate itself.

Applying the fix on the managed PC

Both fixes need the network administrator, because they change trust or inspection policy on a managed machine.

1. Request the inspection CA certificate and confirm with IT that it is the current one, since the fault began on a specific day.
2. Preferred: have IT push a Firefox policy that sets security.enterprise_roots.enabled to true. Firefox then trusts roots already in the Windows store, which is the store Chrome uses. This fixes every inspected host at once and survives CA renewal.
3. Alternative: import the CA into Firefox's own authority list for websites. This works per profile and must be repeated after CA renewal.
4. Alternative on the network side: add the video hosts to the inspection bypass list. This removes the substitute certificate, so Firefox sees the real public chain. Use it where policy allows.
5. Interim: use Chrome, which already trusts the OS store, for the training site.

Confirming the chain validates in both browsers

Reload the failing video in Firefox after a full restart of the browser. The video loads with no interstitial page. Open the padlock certificate view and confirm the issuer matches what the PowerShell read reported after the change: the trusted inspection CA if decryption remains, or a public CA if the host is now bypassed. Play a video that failed and one that never failed, on both the desktop and the laptop, since the fault first appeared on both. Re-run the PowerShell read on each host; every previously failing hostname should now show an issuer the browser trusts.

Pitfalls that repeat on inspected networks

Clicking through or adding an exception is not available under HSTS, and clearing the cached HSTS entry does not fix the chain; the error returns on the next load. Do not disable certificate validation in the browser or install a root CA you did not receive from the network administrator: a rogue root lets its holder read all HTTPS traffic from that machine. A CA renewal on the appliance is the recurring cause of a sudden, all-machines-at-once onset, so ask IT whether the inspection certificate or policy changed on the day the errors began. Fixing only Firefox leaves other tools that carry their own trust store, such as some Java-based clients and command-line utilities, failing against the same inspected hosts.

FAQ