TLS certificates and trust stores ensure that communication between your CMS, data sources, and media players is encrypted, authenticated, and tamper-proof. SpinetiX enforces TLS 1.2+ by default since firmware 4.3.0 — every content sync, every management session, and every data widget request travels over an encrypted channel. No plaintext. No exceptions.
When Certificate Management Matters
- Enterprise PKI integration — when your organization issues its own certificates via internal CA
- 802.1X network authentication — client certificates for device-level network access control
- Internal data sources — when widgets connect to internal HTTPS endpoints using self-signed or enterprise-signed certificates
- Compliance audits — ISO 27001 and SOC2 require documented encryption controls
How TLS Works on SpinetiX
Default TLS Configuration
Out of the box, SpinetiX players enforce TLS 1.2+ for all HTTPS connections. Strong cipher suites only (AES-256-GCM, ChaCha20-Poly1305). Weak protocols (SSL, TLS 1.0, 1.1) are disabled. No configuration needed — the secure default works for most deployments.
Custom CA Trust Store
For environments with internal CAs, upload your CA certificate to the player's trust store. The player will then trust HTTPS connections signed by your CA — critical for accessing internal APIs, dashboards, and data sources over HTTPS. Trust store management is available via the player's management interface or remotely via CMS.
Client Certificates
For 802.1X network authentication, SpinetiX players support client certificates. Each player presents its certificate to the network switch during authentication. This proves device identity — only players with valid certificates receive network access.
Firmware Signing (Separate from TLS)
Firmware images are signed with SpinetiX's private key and verified at boot using TPM 2.0 + UEFI Secure Boot. This is a separate mechanism from TLS — even if someone intercepted a firmware file, they couldn't modify it without SpinetiX's private key.
Key Parameters
| Feature | SpinetiX Support | Notes |
|---|---|---|
| TLS versions | 1.2, 1.3 | SSL, TLS 1.0, 1.1 disabled |
| Cipher suites | AES-256-GCM, ChaCha20-Poly1305 | Strong ciphers only |
| Custom CA certs | Yes — upload to trust store | PEM format |
| Client certificates | Yes — for 802.1X | PKCS#12 or PEM |
| Certificate pinning | Supported | Pin CMS server certificate |
| Firmware signing | RSA + TPM 2.0 + UEFI | Independent of TLS |
| OCSP/CRL | CRL supported | For certificate revocation checks |
Common Mistakes with Certificates
- Using self-signed certificates in production. Self-signed certs work but don't chain to a trusted CA — making MITM detection impossible. Use your enterprise CA or a public CA for production deployments.
- Forgetting certificate expiration. Certificates expire. When they do, TLS connections fail. Players can't sync. Content goes stale. Track expiration dates and automate renewal where possible.
- Not updating the trust store. If you rotate your enterprise CA, all players need the new CA cert in their trust store. Plan trust store updates as part of your CA rotation schedule.
- Assuming TLS alone is enough. TLS encrypts the transport layer. But if someone has CMS credentials, they can publish malicious content over a perfectly encrypted channel. TLS + authentication + RBAC + audit logging = complete security. Network segmentation details →