Hoppscotch Desktop and OS-trusted certificates: a narrow, practical check
Hoppscotch’s v2026.10.0 announcement says the Desktop app can use OS trust when verifying TLS, which makes it worth checking whether an approved corporate CA is already available to the app through the operating system trust store. This article stays narrowly scoped to Desktop HTTP requests, one approved internal HTTPS health endpoint, and an already OS-trusted corporate CA. It does not apply to browser mode, realtime features, or any platform-wide trust outcome.
The safest way to verify this is with a small, non-invasive comparison: note the installed Hoppscotch Desktop version, keep TLS verification turned on, then send one read-only request to a known-good public HTTPS endpoint and one request to an approved internal staging HTTPS health endpoint that does not require credentials. Record whether the transport succeeds separately from the HTTP response status. An HTTP 401 or 403 from the intended HTTPS endpoint is an HTTP-layer response, unlike a certificate error during the TLS handshake. If a proxy generated the response, it does not establish that the origin was reached.
What to record during the check
- Hoppscotch Desktop version
- Operating system version
- The exact internal hostname used for the staging health endpoint
- Whether TLS verification stayed enabled
- Whether the public HTTPS read-only request connected successfully
- Whether the internal HTTPS request connected successfully
- The HTTP status code returned, if any
- The exact sanitized error message if the internal request fails
If the private staging endpoint still fails while the public HTTPS request succeeds, capture the app version, OS version, and the exact sanitized error text, then ask IT to review the hostname, proxy path, and certificate chain. That keeps the investigation focused on routing and trust configuration without weakening verification or importing arbitrary certificates.
One successful request is not proof of fleet-wide trust. It only shows that this device, this app version, and this path were able to complete one TLS connection under the conditions you tested. Broader trust validation needs separate operational checks across the environments that matter to your team.
Why the distinction matters
Certificate trust problems usually show up before any HTTP status exists, because the TLS handshake never finishes. By contrast, a 401 or 403 received from the intended endpoint over a verified TLS connection points to HTTP access controls. Keeping those two outcomes separate helps avoid false alarms and prevents teams from treating authorization errors as certificate issues.
Official references
Hoppscotch v2026.10.0 announcement
