Docker-mailserver: Letsencrypt certs not mounted by default

Created on 28 Jun 2020  路  18Comments  路  Source: tomav/docker-mailserver

Context

When the docker image starts, the start script needs to copy files, including the SSL certificates, but for some reason, it can't see the files.

What is affected by this bug?

SSL certificate files and all their dependents

When does this occur?

When the script runs, on launch

How do we replicate the issue?

This issue occurs on launch. See Environment at the bottom for environment details.

Actual Behavior

The "Setting up SSL" block gives this information:

mail    |   Setting up SSL
mail    |   * TLS configured with 'modern' ciphers
mail    |   * Configuring certificates using cert /tmp/docker-mailserver/ssl/cert and key /tmp/docker-mailserver/ssl/key
mail    | cp: cannot stat '/tmp/docker-mailserver/ssl/cert': No such file or directory
mail    | cp: cannot stat '/tmp/docker-mailserver/ssl/key': No such file or directory
mail    | chmod: cannot access '/etc/postfix/ssl/cert': No such file or directory
mail    | chmod: cannot access '/etc/postfix/ssl/key': No such file or directory
mail    |   * SSL configured with 'Manual' certificates

The cp subprocesses it spawns can't see the files.

Expected behavior (i.e. solution)

The files should be seen and copied.

Your Environment

I have set a fresh installation up on a new installation of Debian.

Starting the server with these commands:

docker-compose down
docker pull tvial/docker-mailserver:latest
docker-compose up mail

For my cert files, I have this configuration:

SSL_TYPE=manual
SSL_CERT_PATH=/etc/letsencrypt/live/mail.giovanh.com/fullchain.pem
SSL_KEY_PATH=/etc/letsencrypt/live/mail.giovanh.com/privkey.pem

(I am aware that this is redundant, as SSL_TYPE=letsencrypt does this, but this is unambiguous.)
The local user and root can both see those two file paths, cat and cp them with no problem. Their permissions are set as , as are the files the symlinks point to.

documentation frozen due to age sstls waiting for contributor action

Most helpful comment

@MakerMatrix I think this issue is still relevant, see my comment in #1698. This issue should be closed by @GiovanH adjusting the documentation - if he is unable I will do it:)

All 18 comments

Using SSL_TYPE=letsencrypt gives a similar error about not being able to see the files, this time caused by the bash [ -e $file ] test rather than a subprocess.

Setting SSL_TYPE=self-signed works correctly with all the same configuration options.

The problem here seems to be that letsencrypt puts symlinks with relative destinations. It is resolved by adding - /etc/letsencrypt/:/etc/letsencrypt/ as a volume in docker-compose.yml. This should probably be documented in the FAQ.

Feel free to update the FAQ where it covers letsencrypt and make a note of this.

@GiovanH what's the current status?

Documentation still just needs tweaking; I haven't gotten around to it because I've been encountering other issues and was trying to get a stable setup before I made any pulls. Anyone is welcome to update the FAQ as detailed above or else I'll get to it myself eventually.

Alright, that's good to hear.

This issue was closed due to one or more of the following reasons:

  1. Age
  2. Contributor inactivity
  3. The issue seems to be resolved

If you think this happened by accident, or feel like this issue was not actually resolved, please feel free to re-open it. If there is an issue you could resolve in the meantime, please open a PR based on the current master branch so we can review it.

Not yet confirmed resolved.

I know, but this is the kind of issue that is kept open forever leading to the situation two month ago where 80 issues were open that should have been closed. Therefore, I'll keep it closed.

You're very welcome to update the FAQ/Wiki when you have the time. Only if you insist on this being reopened I would re-open it.

I'm confused. I get how old issues can pile up even if they've been fixed, so I understand the bot, but you want to keep this issue closed even though you know it isn't resolved?

I messed up your comment, very sorry. I'll fix it immediately. (Wrong button) EDIT: Done.

so I understand the bot

This was me, not a bot:)

you want to keep this issue closed even though you know it isn't resolved?

This is pretty much true, since in my experience these issues are left to rot. For your peace of mind, I'll re-open it since there is a case to be made. But it should not be kept open I indefinitely.

I agree with @aendeavor that hundreds of open issues that nobody is working on adds no value. However, if it can be fixed so much the better!

This issue is marked as stale. Please report back. Otherwise this issue is closed due to inactivity.

I'm having this issue. It isn't stale ;-)

I have tried the suggested fix (adding "- /etc/letsencrypt:/etc/letsencrypt" to the docker-compose file under volumes) and that does not work. My container is using the self-signed certs despite the fact that I now have them mounted at /etc/letsencrypt.

I got it working. It's not clear what I had done wrong, but it is clear that the soft links referenced above are not an issue.

I do think this deserves to be more streamlined. See my issue #1698.

@MakerMatrix I think this issue is still relevant, see my comment in #1698. This issue should be closed by @GiovanH adjusting the documentation - if he is unable I will do it:)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Hamsterman picture Hamsterman  路  3Comments

alen12345 picture alen12345  路  4Comments

Mathieu-R picture Mathieu-R  路  4Comments

H4R0 picture H4R0  路  3Comments

ShuP1 picture ShuP1  路  4Comments