Fixing the Vaultwarden HTTPS secure context error with a reverse proxy

Self-hosters deploying Vaultwarden often encounter a blocking error when accessing the web vault over plain HTTP from another machine. The application refuses to load, citing a missing secure context required for cryptographic operations. This issue stems from browser security standards rather than a software bug, necessitating a specific infrastructure adjustment to resolve.

What happened

When users start Vaultwarden using a basic Docker command that maps port 8000 to port 80, they can access the interface locally via localhost. However, attempting to reach the service from a different device on the local network using an IP address results in a failure. The browser displays an error stating that a secure context is required for the Subtle Crypto API to function. This prevents the login page from rendering correctly and stops any further interaction with the password manager.

The root cause lies in how modern browsers handle sensitive cryptographic functions. Vaultwarden relies on the Web Crypto API to encrypt and decrypt vault data directly within the browser. Browsers restrict access to this API to secure contexts, which are defined as pages served over HTTPS or from localhost. Accessing the service via a local IP address over HTTP does not qualify as a secure context, causing the crypto.subtle object to be undefined and breaking the application's core functionality.

To fix this, the recommended approach involves placing a reverse proxy in front of the Vaultwarden container. The guide demonstrates using Caddy, a web server known for its automatic HTTPS capabilities. By configuring Caddy to handle TLS termination and proxy requests to the Vaultwarden instance, users can establish the necessary secure context. This setup ensures that all client connections, whether from desktop browsers or mobile apps, occur over HTTPS, satisfying both browser security requirements and client application policies.

Key details

• Vaultwarden version 1.37.4 was used in the test environment, running on Docker.
• The error occurs because crypto.subtle is unavailable in non-secure HTTP contexts from remote IPs.
• Localhost access over HTTP renders the page but fails with modern Bitwarden clients requiring HTTPS.
• Caddy was configured with tls internal for testing and reverse_proxy to forward traffic.
• The DOMAIN environment variable must match the HTTPS URL used by clients.
• Open registration should be disabled via SIGNUPS_ALLOWED=false after initial account creation.

Background

Secure contexts are a fundamental web security feature that protects sensitive APIs from being exposed over insecure connections. The Subtle Crypto API, used for high-security operations like key generation and encryption, is only accessible within these contexts. This restriction prevents man-in-the-middle attacks where an attacker could intercept or manipulate cryptographic keys transmitted over plain HTTP. For self-hosted applications like Vaultwarden, which handle sensitive personal data, this browser-level enforcement ensures that encryption happens safely on the client side before data ever reaches the server.

Reverse proxies act as intermediaries between clients and backend services. They handle incoming requests, manage SSL/TLS certificates, and forward traffic to the appropriate internal service. Using a reverse proxy like Caddy simplifies the deployment of HTTPS by automating certificate management. Instead of configuring TLS directly within the application container, which can be complex and error-prone, the proxy handles the secure connection externally. This architecture also allows the backend service to listen only on localhost, reducing its exposure to the network and improving overall security posture.

Why it matters

For teams and individuals running their own software, understanding the distinction between local and network access is crucial. A setup that works perfectly on the host machine may fail completely for other users on the network if HTTPS is not properly configured. This issue highlights the importance of treating self-hosted services with the same security rigor as public-facing applications. Ignoring HTTPS requirements can lead to broken functionality, especially as client applications become stricter about enforcing secure connections.

Moreover, the reliance on browser-based cryptography means that the infrastructure supporting the application must guarantee transport security. Without a valid HTTPS certificate, the entire value proposition of a zero-knowledge password manager is compromised, as the browser cannot perform the necessary encryption steps. Implementing a reverse proxy not only fixes the immediate error but also establishes a scalable foundation for adding more services in the future, all benefiting from centralized certificate management and secure access controls.

What you can do

• Deploy a reverse proxy like Caddy or Nginx in front of your Vaultwarden container.
• Configure the proxy to serve HTTPS using a valid certificate, such as Let's Encrypt for public domains.
• Bind Vaultwarden to 127.0.0.1 only, ensuring it is not directly accessible from the network.
• Set the DOMAIN environment variable to the exact HTTPS URL clients will use to connect.
• Disable open sign-ups by setting SIGNUPS_ALLOWED to false after creating your admin account.
• Verify that mobile clients can connect, ensuring the certificate chain is trusted on all devices.