Hey @hugodutka, have you considered mkcert instead of changing local Chrome settings?

Generally speaking, one would want to generate and install the mkcert CA locally using mkcert -install.
Then create a certificate using mkcert my-workspace.coder or mkcert *.coder (or both mkcert my-workspace.coder *.coder), and then sync those certs into the workspace (either using SCP or mutagen).
Finally, launch Coder (or any other application) with the TLS certificate options configured to the workspace paths where the certificates were copied.

Accessing the HTTPS port will result in a genuine HTTPS connection that is independent of the browser and compatible with CURL and other command-line tools.

I have - setting up custom https certificates is always a headache in my experience. If it's not absolutely necessary, I would rather not do it. Adding the exception in Chrome is much more straightforward.

@ThomasK33 And to give my thoughts on what we should recommend users do: I think developing with Coder VPN shouldn’t require a different workflow to access your web app than developing locally.

If your app is on localhost, you wouldn’t set up an https certificate - it doesn’t provide any benefit. When you develop on a remote machine via VSCode’s Remote SSH, you also don’t set up a cert - you port forward to localhost. The connection is secured by SSH, and it’s fine. With Coder VPN it’s secured with wireguard.

So the only problem a user would currently have is that their browser doesn’t know that the http connection to their workspace is in fact secure. The solutions I see are:

1. Set up an https cert, but go through a complicated setup process on both machines, possibly even having to set up a proxy server in their workspace to handle https, as their web app may not implement support. I worry that for a person that hasn’t done this before this would be too daunting.
2. Trust the workspace origin in their browser if it supports it.
3. Port forward from the workspace origin to localhost with a tool like socat.

I think we should make Coder VPN as easy to use as possible, and I believe 2. is currently the most user-friendly of the bunch. 3. would be the most versatile, but requires using a tool that isn’t that familiar to most developers.

I think it’d be a great feature if Coder VPN natively supported the option to port forward to localhost, so users developing on Safari or Firefox can resolve the trust problem too. If it was already available, I wouldn’t have bothered with option 2.

For future reference, the same can be set in Firefox:

1. Go to about:config, dismiss the warning
2. Tick 'show only modified preferences'
3. search for dom.securecontext.allowlist
4. Select string, click the plus
5. Enter a comma seperated list of domains, e.g. workspace1.coder,workspace2.coder

I have - setting up custom https certificates is always a headache in my experience.

Do you have specific experiences with mkcert in that regard?

If your app is on localhost, you wouldn't set up an https certificate [...]
The connection is secured by SSH, and it's fine.

You do not need a TLS certificate on localhost because the browser considers localhost a secure context, not because of the underlying secure or insecure transport channel.

I think we should make Coder VPN as easy to use as possible, and I believe 2. is currently the most user-friendly of the bunch.

That might be the most user-friendly/quickest in a browser context, but not for any other application running on the local device.

Set up an https cert, but go through a complicated setup process on both machines, possibly even having to set up a proxy server in their workspace to handle https, as their web app may not implement support. I worry that for a person that hasn't done this before this would be too daunting.

While I understand you might have had bad experiences, this statement is an over-exaggeration. I don't see how the steps below for a Coder on Coder workspace are complicated or require a reverse proxy.

Initial mkcert setup:

• mkcert -install

To get a certificate for peach-cricket-38.coder (example name) trusted by your local machine:

• mkcert peach-cricket-38.coder

To get that cert into the workspace:

• scp -P 1 ./peach-cricket-38.coder.pem coder@peach-cricket-38.coder:~/
• scp -P 1 ./peach-cricket-38.coder-key.pem coder@peach-cricket-38.coder:~/

To start coder with a TLS certificate:

• ssh -p 1 coder@peach-cricket-38.coder
• ./scripts/develop.sh -- --tls-enable --tls-cert-file ~/peach-cricket-38.coder.pem --tls-key-file ~/peach-cricket-38.coder-key.pem

Now, I can access it in the browser (https://peach-cricket-38.coder:3443/login) without changing settings or having invalid certificates. Same goes for curl -v https://peach-cricket-38.coder:3443.

I think developing with Coder VPN shouldn't require a different workflow to access your web app than developing locally.

Sure. Yet, using a local exception instead of an actual TLS certificate introduces a drift between how your application will run and behave when deployed into production with a TLS certificate vs. local development without one.
The browsers might behave the same way, but it is not 100% guaranteed to be the case.

Creating a "proper" secure context for a browser does not introduce any changes compared to a production deployment, and issues will be able to surface while developing locally instead of during production runtime.

Do you have specific experiences with mkcert in that regard?

Not anything specific, just vague recollections of some applications not picking up that I trusted a certificate. I haven't used it in a while, it might work well now.

You do not need a TLS certificate on localhost because the browser considers localhost a secure context, not because of the underlying secure or insecure transport channel.

I'm aware of that - maybe my previous comment wasn't clear in that regard. I meant that it'd be fine for the browser to consider *.coder a secure context, since the underlying channel is secure.

That might be the most user-friendly/quickest in a browser context, but not for any other application running on the local device.

Fair. I was mostly considering the web development use case.

this statement is an over-exaggeration. I don't see how the steps below for a Coder on Coder workspace are complicated or require a reverse proxy.

Maybe it's just a matter of opinion. I do believe that these steps are complicated, especially for a person that hasn't done it before, and in relation to the alternatives.

using a local exception instead of an actual TLS certificate introduces a drift between how your application will run and behave when deployed into production with a TLS certificate vs. local development without one.

That's a benefit of using https for sure. However, I think recommending web developers to set up a development environment that'll more closely match their production environment than what they'd usually do with localhost is out of scope of Coder VPN docs. Ensuring their remote experience matches closely what they'd do locally without Coder is.