Question: How to set up Caddy? #162

Closed
opened 2026-02-04 18:06:49 +03:00 by OVERLORD · 9 comments
Owner

Originally created by @MeiRos on GitHub (Dec 17, 2018).

Hi everybody!
Bitwarden_rs is awesome and easy to set up, if people use the easy way.

When I only run Bitwarden_rs Docker image I didn't have any problems. Container was easy to set up. Now I want to use Caddy as reverse proxy on the same server. But nothing works. I have searched guides, info and stories, but none of them solve my problem. I have tryed different settings and results are: bad gateway, too many redirections or something is wrong with ssl connection. Can't get new certs with Caddy and I can't make old ones to work.
I think I have tryed all the possible configurations, even those which I knew won't work.
I have bw.domain.net with my Bitwarden_rs server's IP. Domain.net is with other server's IP. Can this cause problems with Caddy Docker image? With Certbot I didn't have problems.
I tryed to set Caddyfile like the example in the proxy file. Servers were localhost and 127.0.0.1. Both didn't work.
Can't say much about Caddyfile or parameters with docker run command, because I have tryed so many different sets.
If someone have similar setup or knowledge how this should work, some advice would be awesome.
Maybe I'm too tired to figure this out. It's already time to get ready for the night and bed.

Originally created by @MeiRos on GitHub (Dec 17, 2018). Hi everybody! Bitwarden_rs is awesome and easy to set up, if people use the easy way. When I only run Bitwarden_rs Docker image I didn't have any problems. Container was easy to set up. Now I want to use Caddy as reverse proxy on the same server. But nothing works. I have searched guides, info and stories, but none of them solve my problem. I have tryed different settings and results are: bad gateway, too many redirections or something is wrong with ssl connection. Can't get new certs with Caddy and I can't make old ones to work. I think I have tryed all the possible configurations, even those which I knew won't work. I have bw.domain.net with my Bitwarden_rs server's IP. Domain.net is with other server's IP. Can this cause problems with Caddy Docker image? With Certbot I didn't have problems. I tryed to set Caddyfile like the example in the proxy file. Servers were localhost and 127.0.0.1. Both didn't work. Can't say much about Caddyfile or parameters with docker run command, because I have tryed so many different sets. If someone have similar setup or knowledge how this should work, some advice would be awesome. Maybe I'm too tired to figure this out. It's already time to get ready for the night and bed.
Author
Owner

@dani-garcia commented on GitHub (Dec 17, 2018):

My caddyfile is setup like this:

bw.mydomain.com {
    # The negotiation endpoint is also proxied to Rocket
    proxy /notifications/hub/negotiate 0.0.0.0:8000 {
        transparent
    }
    
    # Notifications redirected to the websockets server
    proxy /notifications/hub 0.0.0.0:3012 {
        websocket
    }
    
    # Proxy the Root directory to Rocket
    proxy / 0.0.0.0:8000 {
        transparent
    }

    tls { 
        dns cloudflare 
    }
}

Both the proxy and the server are running in the same machine.

Because I have my domain behind cloudflare, I'm setting the HTTPS with the cloudflare plugin, but you can use the default option or another plugin (check https://caddyserver.com/docs/tls).

To test if the problem is obtaining the certificates, you can try using tls self_signed, which would generate self-signed certificates.

@dani-garcia commented on GitHub (Dec 17, 2018): My caddyfile is setup like this: ``` bw.mydomain.com { # The negotiation endpoint is also proxied to Rocket proxy /notifications/hub/negotiate 0.0.0.0:8000 { transparent } # Notifications redirected to the websockets server proxy /notifications/hub 0.0.0.0:3012 { websocket } # Proxy the Root directory to Rocket proxy / 0.0.0.0:8000 { transparent } tls { dns cloudflare } } ``` Both the proxy and the server are running in the same machine. Because I have my domain behind cloudflare, I'm setting the HTTPS with the cloudflare plugin, but you can use the default option or another plugin (check https://caddyserver.com/docs/tls). To test if the problem is obtaining the certificates, you can try using `tls self_signed`, which would generate self-signed certificates.
Author
Owner

@ghost commented on GitHub (Dec 18, 2018):

@dani-garcia
I want to use Caddy as reverse proxy too but I don't have a public domain. I use Bitwarden only in my local network. What address should I use in your example instead of: "bw.mydomain.com"?
Should I use my BW server IP?

@ghost commented on GitHub (Dec 18, 2018): @dani-garcia I want to use Caddy as reverse proxy too but I don't have a public domain. I use Bitwarden only in my local network. What address should I use in your example instead of: "bw.mydomain.com"? Should I use my BW server IP?
Author
Owner

@MeiRos commented on GitHub (Dec 18, 2018):

Thanks that helped a bit. I got new certs. :)

But still no luck with proxy. Just 502 error.
curl -i localhost:8000 is working.
curl -i bw.domain.net is not. 502 bad gateway.

My Caddyfile is like above except tls my@email.com.

Caddy run command:

   docker run -d -v $(pwd)/Caddyfile:/etc/Caddyfile -v $HOME/.caddy:/root/.caddy -p 80:80 -p 443:443  abiosoft/caddy

Bitwarden_rs run command:

   docker run -d --name bitwarden --log-driver syslog --log-opt tag=$TAG -e SMTP_HOST=smtp.co. -e SMTP_FROM=no-reply@domain.net -e SMTP_PORT=587 -e SMTP_SSL=true -e SMTP_USERNAME=user -e SMTP_PASSWORD=xxyyzx -e SIGNUPS_ALLOWED=false -e SERVER_ADMIN_EMAIL=im.admin@gmail.com -p 8000:80 -p 3012:3012 -v /bw-data/:/data/  mprasil/bitwarden:latest
   #ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), allow (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW IN    Anywhere                  
443/tcp                    ALLOW IN    Anywhere                  
SSH                        ALLOW IN    Anywhere

I don't understand what is wrong. Some help is needed. Can you see what is wrong?

@MeiRos commented on GitHub (Dec 18, 2018): Thanks that helped a bit. I got new certs. :) But still no luck with proxy. Just 502 error. curl -i localhost:8000 is working. curl -i bw.domain.net is not. 502 bad gateway. My Caddyfile is like above except tls my@email.com. Caddy run command: ``` docker run -d -v $(pwd)/Caddyfile:/etc/Caddyfile -v $HOME/.caddy:/root/.caddy -p 80:80 -p 443:443 abiosoft/caddy ``` Bitwarden_rs run command: ``` docker run -d --name bitwarden --log-driver syslog --log-opt tag=$TAG -e SMTP_HOST=smtp.co. -e SMTP_FROM=no-reply@domain.net -e SMTP_PORT=587 -e SMTP_SSL=true -e SMTP_USERNAME=user -e SMTP_PASSWORD=xxyyzx -e SIGNUPS_ALLOWED=false -e SERVER_ADMIN_EMAIL=im.admin@gmail.com -p 8000:80 -p 3012:3012 -v /bw-data/:/data/ mprasil/bitwarden:latest ``` ``` #ufw status verbose Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), allow (routed) New profiles: skip To Action From -- ------ ---- 80/tcp ALLOW IN Anywhere 443/tcp ALLOW IN Anywhere SSH ALLOW IN Anywhere ``` I don't understand what is wrong. Some help is needed. Can you see what is wrong?
Author
Owner

@dani-garcia commented on GitHub (Dec 18, 2018):

@Haxy I'm pretty sure that you can use your IP and port, yes.

@MeiRos Are you doing both curls from the same machine? Try changing the caddyfile to use localhost instead of 0.0.0.0, maybe it's not recognizing it. Otherwise, try setting caddy without tls enabled to see if that works.

@dani-garcia commented on GitHub (Dec 18, 2018): @Haxy I'm pretty sure that you can use your IP and port, yes. @MeiRos Are you doing both curls from the same machine? Try changing the caddyfile to use localhost instead of 0.0.0.0, maybe it's not recognizing it. Otherwise, try setting caddy without tls enabled to see if that works.
Author
Owner

@mrwulf commented on GitHub (Dec 19, 2018):

Or, if you really want a DNS name (or to test!), check out this site: http://nip.io/
You basically just use bw.<IP Address>.nip.io as the DNS name and it will get resolved back to <IP Address>

@mrwulf commented on GitHub (Dec 19, 2018): Or, if you really want a DNS name (or to test!), check out this site: http://nip.io/ You basically just use **bw.\<IP Address\>.nip.io** as the DNS name and it will get resolved back to **\<IP Address\>**
Author
Owner

@MeiRos commented on GitHub (Dec 19, 2018):

@dani-garcia
I did curls on the same server where are Bitwarden_rs and Caddy.

Error.log with localhost in the caddyfile

19/Dec/2018:09:11:08 +0000 [ERROR 502 /] dial tcp 127.0.0.1:8000: connect: connection refused
19/Dec/2018:09:11:08 +0000 [ERROR 502 /favicon.ico] dial tcp 127.0.0.1:8000: connect: connection refused
19/Dec/2018:09:11:13 +0000 [ERROR 502 /] dial tcp 127.0.0.1:8000: connect: connection refused
19/Dec/2018:09:11:13 +0000 [ERROR 502 /favicon.ico] dial tcp 127.0.0.1:8000: connect: connection refused

Curl -Iv https://bw.domain.net (with 0.0.0.0)

/etc# curl -Iv https://bw.domain.net                         * Rebuilt URL to: https://bw.domain.net/                                      *   Trying ::1...                                                            * TCP_NODELAY set                                                            * Connected to bw.domain.net (::1) port 443 (#0)                              * ALPN, offering h2                                                          * ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=bw.domain.net 
*  start date: Dec 17 10:36:21 2018 GMT
*  expire date: Mar 17 10:36:21 2019 GMT
*  subjectAltName: host "bw.domain.net" matched cert's "bw.domain.net"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x563dd854d900)
> HEAD / HTTP/2
> Host: bw.domain.net
> User-Agent: curl/7.58.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 502 
HTTP/2 502 
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< server: Caddy
server: Caddy
< x-content-type-options: nosniff
x-content-type-options: nosniff
< content-length: 16
content-length: 16
< date: Wed, 19 Dec 2018 08:31:06 GMT
date: Wed, 19 Dec 2018 08:31:06 GMT

< 
* Connection #0 to host bw.domain.net left intact

Results are same with 'localhost' setting. Only numbers after 'easy handle' changes.

Ssl off

/etc# curl -Iv http://bw.domain.net * Rebuilt URL to: http://bw.domain.net/
*   Trying ::1...
* TCP_NODELAY set
* Connected to bw.domain.net (::1) port 80 (#0)
> HEAD / HTTP/1.1
> Host: bw.domain.net 
> User-Agent: curl/7.58.0
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host bw.domain.net left intact
curl: (52) Empty reply from server

With Google I found this. https://github.com/mholt/caddy/issues/1944 Added bw.domain.net to hosts file. No help.

Still no working reverse proxy. Do you still have ideas to try? :)

@MeiRos commented on GitHub (Dec 19, 2018): @dani-garcia I did curls on the same server where are Bitwarden_rs and Caddy. Error.log with localhost in the caddyfile ``` 19/Dec/2018:09:11:08 +0000 [ERROR 502 /] dial tcp 127.0.0.1:8000: connect: connection refused 19/Dec/2018:09:11:08 +0000 [ERROR 502 /favicon.ico] dial tcp 127.0.0.1:8000: connect: connection refused 19/Dec/2018:09:11:13 +0000 [ERROR 502 /] dial tcp 127.0.0.1:8000: connect: connection refused 19/Dec/2018:09:11:13 +0000 [ERROR 502 /favicon.ico] dial tcp 127.0.0.1:8000: connect: connection refused ``` Curl -Iv https://bw.domain.net (with 0.0.0.0) ``` /etc# curl -Iv https://bw.domain.net * Rebuilt URL to: https://bw.domain.net/ * Trying ::1... * TCP_NODELAY set * Connected to bw.domain.net (::1) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=bw.domain.net * start date: Dec 17 10:36:21 2018 GMT * expire date: Mar 17 10:36:21 2019 GMT * subjectAltName: host "bw.domain.net" matched cert's "bw.domain.net" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x563dd854d900) > HEAD / HTTP/2 > Host: bw.domain.net > User-Agent: curl/7.58.0 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 502 HTTP/2 502 < content-type: text/plain; charset=utf-8 content-type: text/plain; charset=utf-8 < server: Caddy server: Caddy < x-content-type-options: nosniff x-content-type-options: nosniff < content-length: 16 content-length: 16 < date: Wed, 19 Dec 2018 08:31:06 GMT date: Wed, 19 Dec 2018 08:31:06 GMT < * Connection #0 to host bw.domain.net left intact ``` Results are same with 'localhost' setting. Only numbers after 'easy handle' changes. Ssl off ``` /etc# curl -Iv http://bw.domain.net * Rebuilt URL to: http://bw.domain.net/ * Trying ::1... * TCP_NODELAY set * Connected to bw.domain.net (::1) port 80 (#0) > HEAD / HTTP/1.1 > Host: bw.domain.net > User-Agent: curl/7.58.0 > Accept: */* > * Empty reply from server * Connection #0 to host bw.domain.net left intact curl: (52) Empty reply from server ``` With Google I found this. https://github.com/mholt/caddy/issues/1944 Added bw.domain.net to hosts file. No help. Still no working reverse proxy. Do you still have ideas to try? :)
Author
Owner

@sitic commented on GitHub (Dec 19, 2018):

@MeiRos The problem is that localhost/127.0.0.1 inside the caddy docker container is not the IP of the host, but rather the local caddy container.
You either need to set the proxy target IP in the caddyfile to the local IP of the host (like 192.168. ...) and allow those connections with iptables/ufw, or (highly recommanded) use docker-compose.

See https://github.com/dani-garcia/bitwarden_rs/issues/126#issuecomment-417872681 for an docker-compose example, it will automatically create a local docker network which will allow the caddy and bitwarden_rs containers to talk to each other.

@sitic commented on GitHub (Dec 19, 2018): @MeiRos The problem is that localhost/127.0.0.1 inside the caddy docker container is not the IP of the host, but rather the local caddy container. You either need to set the proxy target IP in the caddyfile to the local IP of the host (like 192.168. ...) and allow those connections with iptables/ufw, or (highly recommanded) use [docker-compose](https://docs.docker.com/compose/). See https://github.com/dani-garcia/bitwarden_rs/issues/126#issuecomment-417872681 for an docker-compose example, it will automatically create a local [`docker network`](https://docs.docker.com/engine/reference/commandline/network/#child-commands) which will allow the caddy and bitwarden_rs containers to talk to each other.
Author
Owner

@MeiRos commented on GitHub (Dec 20, 2018):

Thanks @sitic it was easy to setup with docker-compose. I thought it's easy to use 'docker run' too, but it needs more work than I can do.

@MeiRos commented on GitHub (Dec 20, 2018): Thanks @sitic it was easy to setup with docker-compose. I thought it's easy to use 'docker run' too, but it needs more work than I can do.
Author
Owner

@dani-garcia commented on GitHub (Jan 11, 2019):

I think this is solved by now and we can close it

@dani-garcia commented on GitHub (Jan 11, 2019): I think this is solved by now and we can close it
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#162