Caddy on Docker (Portainer) to allow HTTPS for VaultWarden

Help
#1

1. Caddy version (caddy version):

Caddy V2.4.6 (docker)

2. How I run Caddy:

Caddy is installed on Docker (Portainer), on a local network (ubuntu-server).

a. System environment:

  • Hardware is a NUC running Proxmox
  • Caddy is installed on an ubuntu VM running Docker.
  • VaultWarden is installed as a separate container in Docker too.

I have a separate RasperryPi running PiHole

b. Command:

Run from Portainer with the following:
CMD = caddy run --config /etc/caddy/Caddyfile --adapter caddyfile
Volumes:
/var/lib/docker/volumes/caddy/config >> /config
/var/lib/docker/volumes/caddy/data >> /data
/var/lib/docker/volumes/caddy/Caddyfile| >> /etc/caddy/Caddyfile
/var/lib/docker/volumes/caddy/site >> /usr/share/caddy

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

have tried:

vault.ubuntu-server {
reverse_proxy localhost:8000
}

and also tried:

vault.localhost {
reverse_proxy localhost:8000
}

Paste config here, replacing this text.
Use `caddy fmt` to make it readable.
DO NOT REDACT anything except credentials.
LEAVE DOMAIN NAMES INTACT.
Make sure the backticks stay on their own lines.

3. The problem I’m having:

I am unable to have Caddy serve VaultWarden as HTTPS. VaultWarden is on the same server, using port 8000 mapped to 80 in Portainer. VaultWarden opens ok, but I need to enable SSL to be able to set-up and continue

4. Error messages and/or full log output:

No errors as such. Just can’t get Caddy to work with this set-up

5. What I already tried:

I have tried several CaddyFile options.

6. Links to relevant resources:

#2

Caddy will have logs. Check the container’s log outputs.

Did you bind Caddy to ports 80 and 443 on the host machine?

Do you have your local DNS server (I assume pihole) resolving that hostname to the IP address of your server?

I can’t suggest anything without actually seeing evidence of the errors. Check your logs, explain what’s not working. Make a request with curl -v to show what happens.

And please place your logs and config within code blocks in your post, between the lines with ``` backticks. Code blocks will makes sure formatting is preserved. It’s hard to read otherwise. (Also see the help topic template, you were meant to paste your logs within those code fences where it says “Paste config here”)

#3

Hi - thank you Francis for responding.

I think that Caddy is kind of working but I don’t think the CaddyFile is correct. Yes, I bind ports 80 and 443 on the host machine. Yes, the local DNS is Pi-hole and this is resolving back to the Caddy server.

The issue is that Chrome is saying the connection is Not Secure when connecting both internally (with Pihole DNS forwarding to Caddy) or externally (where the web-server A Host points to Caddy IP).

This is an example of the CaddyFile where ‘service’ is accessible from within the network (local.lan) and externally (example.com):

{
local_certs
}
service.local.lan {
reverse_proxy 192.168.X.Y:8000
}
service.example.com {
reverse_proxy 192.168.X.Y:8000
}

But in both cases, I get Not Secure. I think that this is issuing local certs in both cases, so need to only issue local certs to the local version (local.lan) and not to external. But, not sure how do do this within the CaddyFile.

#4

Right, the local_certs global option just makes Caddy issue local certs for all sites regardless of whether it’s a public domain or not. It’s more meant as a quick switch to flip when testing things to avoid hitting public ACME issuers.

Instead, you should use the tls internal directive on any sites you want to use local certs.

As I said, please use backticks for code blocks when posting config or logs. Whitespace gets lost otherwise, making it harder to read.

#5

Thank you Francis.

Caddyfile updated, and seems to be running. This is the caddyfile:

vault.local.lan {
reverse_proxy 192.168.1.25:8000
tls internal
}

vault.dsewell.co.uk {
reverse_proxy 192.168.1.25:8000
}

This is the log:

{“level”:“warn”,“ts”:1641385544.1419122,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [vault.dsewell.co.uk]: no OCSP server specified in certificate”}
{“level”:“info”,“ts”:1641386929.921096,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“vault.dsewell.co.uk”]}
{“level”:“info”,“ts”:1641386929.922538,“logger”:“tls.obtain”,“msg”:“acquiring lock”,“identifier”:“vault.dsewell.co.uk”}
{“level”:“info”,“ts”:1641386929.9272904,“logger”:“tls.obtain”,“msg”:“lock acquired”,“identifier”:“vault.dsewell.co.uk”}
{“level”:“info”,“ts”:1641386929.9300933,“logger”:“tls.issuance.acme”,“msg”:“waiting on internal rate limiter”,“identifiers”:[“vault.dsewell.co.uk”],“ca”:“https://acme-v02.api.letsencrypt.org/directory",“account”:"”}
{“level”:“info”,“ts”:1641386929.93019,“logger”:“tls.issuance.acme”,“msg”:“done waiting on internal rate limiter”,“identifiers”:[“vault.dsewell.co.uk”],“ca”:“https://acme-v02.api.letsencrypt.org/directory",“account”:"”}
{“level”:“info”,“ts”:1641386930.7908323,“logger”:“tls.issuance.acme.acme_client”,“msg”:“trying to solve challenge”,“identifier”:“vault.dsewell.co.uk”,“challenge_type”:“http-01”,“ca”:“https://acme-v02.api.letsencrypt.org/directory”}
{“level”:“info”,“ts”:1641386931.0492628,“logger”:“tls.issuance.acme”,“msg”:“served key authentication”,“identifier”:“vault.dsewell.co.uk”,“challenge”:“http-01”,“remote”:“18.192.36.99:25892”,“distributed”:false}
{“level”:“info”,“ts”:1641386931.3714836,“logger”:“tls.issuance.acme”,“msg”:“served key authentication”,“identifier”:“vault.dsewell.co.uk”,“challenge”:“http-01”,“remote”:“34.221.255.206:23544”,“distributed”:false}
{“level”:“info”,“ts”:1641386931.4222786,“logger”:“tls.issuance.acme”,“msg”:“served key authentication”,“identifier”:“vault.dsewell.co.uk”,“challenge”:“http-01”,“remote”:“3.19.56.43:63164”,“distributed”:false}
{“level”:“info”,“ts”:1641386931.4661028,“logger”:“tls.issuance.acme”,“msg”:“served key authentication”,“identifier”:“vault.dsewell.co.uk”,“challenge”:“http-01”,“remote”:“66.133.109.36:14062”,“distributed”:false}
{“level”:“info”,“ts”:1641386932.2468717,“logger”:“tls.obtain”,“msg”:“certificate obtained successfully”,“identifier”:“vault.dsewell.co.uk”}
{“level”:“info”,“ts”:1641386932.2469459,“logger”:“tls.obtain”,“msg”:“releasing lock”,“identifier”:“vault.dsewell.co.uk”}
{“level”:“info”,“ts”:1641387035.5147676,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“vault.local.lan”,“media.local.lan”,“vault.dsewell.co.uk”,“pihole.local.lan”]}
{“level”:“warn”,“ts”:1641387035.5158372,“logger”:“tls”,“msg”:“stapling OCSP”,“error”:“no OCSP stapling for [vault.dsewell.co.uk]: no OCSP server specified in certificate”}
{“level”:“info”,“ts”:1641393318.5865958,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“vault.dsewell.co.uk”,“pihole.local.lan”,“vault.local.lan”,“media.local.lan”]}
{“level”:“info”,“ts”:1641394185.3117416,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“media.local.lan”,“vault.dsewell.co.uk”,“pihole.local.lan”,“vault.local.lan”]}

This is the message in Chrome:
image

From the log, I guess the issue is something to do with OCSP server specified? Is there a missing directive or setting I need to use to make this secure?

(hope the mark-up is ok)

Regards

#6

You used block quotes. Use code blocks, which involves putting 3 backticks on the lines immediately preceding and following the logs/config.

it ends up looking like this

There’s also a button in the reply editor that looks like </>

That’s strange, but harmless.

I tried to load https://vault.dsewell.co.uk myself, and it seems to work fine (HTTPS, with a valid publicly trusted cert). So you should be good to go.

1 Like
#7

Thank you for your help :slight_smile: :grin:

Sorry for the very poor use of markup :frowning:

2 Likes
#8

This topic was automatically closed after 30 days. New replies are no longer allowed.