[GH-ISSUE #6401] [Security] Default Port Should be 443 #2420

New issue

Closed

opened 2026-03-03 02:18:09 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 02:18:09 +03:00

Owner

Originally created by @cxtal on GitHub (Oct 27, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6401

Prerequisites

I have searched the existing Closed AND Open Issues AND Discussions
I have searched and read the documentation

Vaultwarden Support String

N/A

Vaultwarden Build Version

v1.34.0

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

traefik 3.4.4

Host/Server Operating System

Linux

Operating System Version

No response

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Connect with SSL client to port 80.

Expected Result

Vaultwarden loads.

Actual Result

Vaultwarden doesn't load.

Logs

Screenshots or Videos

No response

Additional Context

Thank you for the wonderful project.

A small suggestion that exists with the default Vaultwarden Docker container is that it expects HTTPs traffic over port 80 when port 80 is defined by IANA as a HTTP port only and the correct port for HTTPs is 443 (RFC6335 / RFC9110).

One would think this is not a problem, right? The port in this case is just a TCP socket on the lower levels but this problem manages to throw the Traefik reverse-proxy off and the container must be labeled such that Traefik accepts to start TLS/SSL over port 80 or through the custom exposed port.

It would be standards-compliant for Vaultwarden to start its HTTPs listener on port 443, even internal to the Docker container because reverse-proxies like Traefik hook into the internal network, or to pick any non-reserved port for SSL traffic. Some other software behaves the same; Firefox is also thrown off if a server responds with a TLS/SSL session request over 80, it does not even proceed, it just throws an error at the user claiming that a website tried to initiate HTTPs over HTTP.

I am just mentioning this because it's not a difficult issue to debug, but due to the non-standards-compliant behavior some clients might be thrown off by default depending on how seriously they take the port assignment definitions.

Originally created by @cxtal on GitHub (Oct 27, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6401 ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String N/A ### Vaultwarden Build Version v1.34.0 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy traefik 3.4.4 ### Host/Server Operating System Linux ### Operating System Version _No response_ ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce - Connect with SSL client to port 80. ### Expected Result - Vaultwarden loads. ### Actual Result - Vaultwarden doesn't load. ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context Thank you for the wonderful project. A small suggestion that exists with the default Vaultwarden Docker container is that it expects HTTPs traffic over port 80 when port 80 is defined by IANA as a HTTP port only and the correct port for HTTPs is 443 (RFC6335 / RFC9110). One would think this is not a problem, right? The port in this case is just a TCP socket on the lower levels but this problem manages to throw the Traefik reverse-proxy off and the container must be labeled such that Traefik accepts to start TLS/SSL over port 80 or through the custom exposed port. It would be standards-compliant for Vaultwarden to start its HTTPs listener on port 443, even internal to the Docker container because reverse-proxies like Traefik hook into the internal network, or to pick any non-reserved port for SSL traffic. Some other software behaves the same; Firefox is also thrown off if a server responds with a TLS/SSL session request over 80, it does not even proceed, it just throws an error at the user claiming that a website tried to initiate HTTPs over HTTP. I am just mentioning this because it's not a difficult issue to debug, but due to the non-standards-compliant behavior some clients might be thrown off by default depending on how seriously they take the port assignment definitions.