Skip to content
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

certbot support broken in ≥ 4.9-0 #381

Open
andersk opened this issue Dec 23, 2022 · 3 comments · May be fixed by #391
Open

certbot support broken in ≥ 4.9-0 #381

andersk opened this issue Dec 23, 2022 · 3 comments · May be fixed by #391

Comments

@andersk
Copy link
Member

andersk commented Dec 23, 2022

Between 4.8-1 and 4.9-0, we backported zulip/zulip#20512 and started unconditionally installing certbot, resulting in /etc/letsencrypt existing in the base image, so this symlink never happens. This results in a broken symlink where the certificate should be.

root@70b1222620d1:/# namei /etc/ssl/certs/zulip.combined-chain.crt
f: /etc/ssl/certs/zulip.combined-chain.crt
 d /
 d etc
 d ssl
 d certs
 l zulip.combined-chain.crt -> /data/certs/zulip.combined-chain.crt
   d /
   d data
   d certs
     zulip.combined-chain.crt - No such file or directory

Discussion.

@thelazyoxymoron
Copy link

Getting this on my self-hosted docker instance as well, even though I'm using an external certificate deployed by Nginx Proxy Manager to talk to the zulip container. I'm able to connect to the deployed URL, however zulip clients intermittently throw a self-signed certificate error.

@andersk
Copy link
Member Author

andersk commented Jan 12, 2023

@thelazyoxymoron You’re seeing something unrelated that you’re going to have to debug on the Nginx Proxy Manager side. This issue is about the internal Certbot support inside docker-zulip.

klardotsh added a commit to klardotsh/docker-zulip that referenced this issue Feb 28, 2023
Zulip Server 4.9+ regressed Docker setups by always creating a
/etc/letsencrypt directory in the top layer of the Docker container,
meaning it couldn't be symlinked over from the volume mount. Since that
volume mount has useful properties (providing and/or overriding
LetsEncrypt setting), restore it and copy the in-image configs into the
volume as defaults if and only if those files don't already exist in the
volume.

Fixes zulip#381.
klardotsh added a commit to klardotsh/docker-zulip that referenced this issue Feb 28, 2023
Zulip Server 4.9+ regressed Docker setups by always creating a
/etc/letsencrypt directory in the top layer of the Docker container,
meaning it couldn't be symlinked over from the volume mount. Since that
volume mount has useful properties (providing and/or overriding
LetsEncrypt setting), restore it and copy the in-image configs into the
volume as defaults if and only if those files don't already exist in the
volume.

Fixes zulip#381.
klardotsh added a commit to klardotsh/docker-zulip that referenced this issue Feb 28, 2023
Zulip Server 4.9+ regressed Docker setups by always creating a
/etc/letsencrypt directory in the top layer of the Docker container,
meaning it couldn't be symlinked over from the volume mount. Since that
volume mount has useful properties (providing and/or overriding
LetsEncrypt setting), restore it and copy the in-image configs into the
volume as defaults if and only if those files don't already exist in the
volume.

Fixes zulip#381.
@InfinityRed-Code
Copy link

Was anyone able to fix this or work around this?
I thought of using self signed certs in the container and using certbot on the host itself. But I dont know if this works with passing through to the container. With one Org this might work fine but I want to host several orgs with differrent domains where the main org wold be smth like: zulip.example.com anf the following ones org1.zulip.example.com ...
Maybe even a wildcard cert on the host to adress all domains.
Has anyone tried this or experimented with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants