Closed SwissOS closed 1 month ago
I think I have found the problem inside postfix.sh. The logic to write sni.map is incorrect. Here are the original lines:
# create sni configuration
if [[ "${SKIP_LETS_ENCRYPT}" =~ ^([yY][eE][sS]|[yY])+$ ]]; then
echo -n "" > /opt/postfix/conf/sni.map
else
echo -n "" > /opt/postfix/conf/sni.map;
for cert_dir in /etc/ssl/mail/*/ ; do
if [[ ! -f ${cert_dir}domains ]] || [[ ! -f ${cert_dir}cert.pem ]] || [[ ! -f ${cert_dir}key.pem ]]; then
continue;
fi
IFS=" " read -r -a domains <<< "$(cat "${cert_dir}domains")"
for domain in "${domains[@]}"; do
echo -n "${domain} ${cert_dir}key.pem ${cert_dir}cert.pem" >> /opt/postfix/conf/sni.map;
echo "" >> /opt/postfix/conf/sni.map;
done
done
fi
postmap -F hash:/opt/postfix/conf/sni.map;
In fact, the logic should be to check first if the files cert.pem and key.pem are present in /etc/ssl (which they should if you follow the documentation to copy those files there in the first place), in which case the sni.map should be a single line consisting of: ${MAILCOW_HOSTNAME} ${cert_dir}key.pem ${cert_dir}cert.pem So, do not check if SKIP_LETS_ENCRYPT is true, but check if those 2 files are there first. The rest for multiple domains should be kept the same.
I am unfortunately not a programmer, and cannot make a PR for those changes, even if they are probably very trivial to most here (sorry!). If someone can write the changes, I can test them. Thank you in advance!
+1 for this issue, it affects my setup where I have mailcow behind a reverse proxy which is responsible for the SSL cert management and the relevant cert files are being mapped into /etc/ssl/mail via the volumes: section for postfix-mailcow in my docker-compose.override.yml.
Note that I have multiple domains in mailcow, but one cert includes them all using the Subject Alternative Name approach, so I don't think this is related to having a single domain for mailcow, I think it's just about SKIP_LETS_ENCRYPT = y assuming that there won't be any cert files for postfix.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
ARM64 (aarch64)
Operating System:
Ubuntu 22.04 LTS
Server/VM specifications:
16 GB/4 cores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
none
Docker version:
26.0.0
docker-compose version or docker compose version:
2.25.0
mailcow version:
2024-02
Reverse proxy:
Nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: