Dovecot and Postfix now (idk when it changed) use a subdirectory of data/assets/ssl, named after MAILCOW_HOSTNAME, in which the cert and key for the domain are located. This PR modified a script to add a copy of the certificates generated by Caddy inside this folder. It was tested for a single domain installation.
Description of the PR
I use mailcow behind Caddy reverse-proxy, configured as in the docs, with the script to automatically copy the certs into mailcow when they get updated.
After being warned by my e-mail client yesterday that my certificate was expired, event though the HTTPS access was fine, I used the expiry_dates.sh helper script and it gave me this output :
$ sudo bash helper-scripts/expiry-dates.sh
Could not read certificate from <stdin>
Unable to load certificate
TLS expiry dates:
Postfix: Apr 10 16:46:11 2024 GMT
Dovecot: Apr 10 16:46:11 2024 GMT
Nginx:
I don't know about the first error, but Postfix and Dovecot seem use an old certificate and not the one that Caddy uses.
Checking the script, I figured it compared the certificates hash of both Caddy and mailcow (located in mailcow-dockerized/data/assets/ssl), so I checked the hashes, which were identical, then the certs manually, same.
Finally, a quick look at the content of data/assets/ssl gave me the solution: there was a new folder named after my host domain (MAILCOW_HOSTNAME or your.domain.tld in the docs) which itself contained a copy of one of my previous certificate and key, which expired yesterday.
I tried moving the two files from data/assets/ssl into this folder, rebooted the Nginx, Postfix and Dovecot containers, but I got another error from my e-mail client and the web interface gave a blank page, so I kept two copies of the two files in both folders (rebooted the containers) and it worked.
Here is a tree view of my mailcow-dockerized/data/assets/ssl to help you visualize.
data/assets/ssl
├── acme
│ ├── account.pem
│ └── key.pem
├── backups # this folder is irrelevant, it contains backups of the previous certificates for my domain
├── cert.pem # already updated by the script
├── dhparams.pem
├── key.pem # already updated by the script
└── my.domain.tld
├── acme.csr
├── cert.pem # now also updated by the script
├── domains
└── key.pem # now also updated by the script
I also added a couple of bash variables in the script in order to make it cleaner, more maintainable and more readable for sys admins.
TLDR
Dovecot and Postfix now (idk when it changed) use a subdirectory of
data/assets/ssl, named after MAILCOW_HOSTNAME, in which the cert and key for the domain are located. This PR modified a script to add a copy of the certificates generated by Caddy inside this folder. It was tested for a single domain installation.Description of the PR
I use mailcow behind Caddy reverse-proxy, configured as in the docs, with the script to automatically copy the certs into mailcow when they get updated.
After being warned by my e-mail client yesterday that my certificate was expired, event though the HTTPS access was fine, I used the
expiry_dates.shhelper script and it gave me this output :I don't know about the first error, but Postfix and Dovecot seem use an old certificate and not the one that Caddy uses.
Checking the script, I figured it compared the certificates hash of both Caddy and mailcow (located in
mailcow-dockerized/data/assets/ssl), so I checked the hashes, which were identical, then the certs manually, same.Finally, a quick look at the content of
data/assets/sslgave me the solution: there was a new folder named after my host domain (MAILCOW_HOSTNAMEoryour.domain.tldin the docs) which itself contained a copy of one of my previous certificate and key, which expired yesterday.I tried moving the two files from
data/assets/sslinto this folder, rebooted the Nginx, Postfix and Dovecot containers, but I got another error from my e-mail client and the web interface gave a blank page, so I kept two copies of the two files in both folders (rebooted the containers) and it worked.Here is a tree view of my
mailcow-dockerized/data/assets/sslto help you visualize.I also added a couple of bash variables in the script in order to make it cleaner, more maintainable and more readable for sys admins.