Does CHIME use SSL / HTTPS?

CHIME is a web-based application designed for use within secure, private networks at client locations. It does not use traditional username and password authentication; instead, it relies on network-level access control. If a device is allowed on the local network, it is allowed to access CHIME. This simplifies deployment and management and improves user experience, while maintaining appropriate levels of access control for the intended use environment.

Because CHIME is only accessible from within a client’s trusted network, deploying HTTPS does not meaningfully increase security. Any user capable of intercepting traffic on the network would already have direct access to the application itself. In this context, SSL/TLS encryption does not prevent any real-world threats beyond those already mitigated by existing network security.

Implementing HTTPS would also introduce complexity and risks. For example, automated SSL certificate deployment and renewal typically requires inbound internet access, which is intentionally disabled on CHIME servers for security reasons. Enabling inbound connectivity to support SSL certificate renewal would create a broader attack surface and go against the design philosophy of minimizing dependencies and potential vulnerabilities (a.k.a. “you can’t hack what you can’t see”).

For these reasons, CHIME is typically served over plain HTTP within controlled environments, where security is enforced at the network level. This approach is consistent with its role as an internal tool and reflects a deliberate balance between security, usability, reliability, and risk.

Note: if an organization must have HTTPS for internal reasons, please speak to your Account Manager. We can make the change, even though we don’t recommend it and, for the reasons above, believe it increases overall risk.