Skip to content

docs: update Let's Encrypt instructions #3768

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -181,7 +181,7 @@ At this point, you should be able to access code-server via
server_name mydomain.com;

location / {
proxy_pass http://localhost:8080/;
proxy_pass https://localhost:8080/;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm if it's https, shouldn't it be on 8443?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know nothing about setting up NGINX + Let's Encrypt so I would take your word over mine. Here's the discussion if you want to know why I opened the PR: #3709

also cc @code-asher

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m a noob and know nothing about anything. I just found that when following the instructions as written, I got a redirect error when visiting my domain from a remote device. It got caught in a 302 redirect loop, constantly being redirected to https://domain.com. I tried tweaking a couple of things in the nginx config, and this was the change which made it work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. I'm confused about the discussion but can offer you some more context on how people typically use reverse proxies.

Many services default to HTTP (without encryption) because it avoids the need to handle TLS certificates. My guess is that Express does this by default, and code-server runs without encryption. However, it's unsafe to access things over HTTP over the Internet, because anyone inbetween the browser and server can intercept and modify traffic, including view credentials, which are sent in plaintext when not using HTTPS.

So the solution that many people use is to have a reverse proxy that receives the HTTPS traffic, decrypts it, and passes the connection through to code-server.

I believe this nginx configuration is saying: when a user accesses https://joes-codeserver-site.joesdomain.com, we want to decrypt the traffic and pass it through to localhost:8080. The proxy_pass part refers to the actual host protocol and port of the service (in this case code-server) that we're reverse proxying, and the reason we needed http is because we want to decrypt the incoming traffic before handing it to code-server.

If we use https here, then it means that nginx will decrypt and re-encrypt traffic for localhost, but the code-server backend service will be confused because it's expecting unencrypted traffic, not encrypted traffic.

The docs for proxy_pass aren't super friendly, but I think this is why the examples all use http, since it's relatively common to use nginx in a configuration where it terminates TLS traffic and passes decrypted traffic to code-server.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup http is correct here. With regards to the discussion one possibility is that code-server is being started with --cert? With that code-server will redirect from http to https. So the page redirects, nginx makes another request to http, code-server redirects again, and on and on we go.

If this is the case then starting without --cert would resolve the issue.

The only use case for https here I think is if you need to encrypt traffic internally (from NGINX to code-server) for some reason. I don't think most people's threat models need to account for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhh, got it. I'm going to close this PR then. But it does sound like we could flesh out this guide more. Once we are done with the testing priority, I can do a run through the docs and address things like this.

Noting in the roadmap

proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
Expand Down