Different certificates with different methods

xlx

Hi guys,

I’m not able to set up the custom certificate renewal process. I’ve rigorously worked through the Advanced SSL documentation.

bash helper-scripts/expiry-dates.sh displays the new expiration dates from the new certificate. So everything seems fine.

Even openssl s_client -starttls smtp -connect MAILCOW_HOSTNAME:587 | openssl x509 -noout -text, openssl s_client -connect MAILCOW_HOSTNAME:465 | openssl x509 -noout -text, openssl s_client -starttls imap -connect MAILCOW_HOSTNAME:143 | openssl x509 -noout -text and openssl s_client -connect MAILCOW_HOSTNAME:993 | openssl x509 -noout -text shows the new certificate information.

However, Apple Mail shows that it can’t verify the server’s identity because the certificate has expired (it is the old certificate expiration).

And if I’m using the command openssl s_client -showcerts -connect MAILCOW_HOSTNAME:465 -servername MAILCOW_HOSTNAME for example, the old certificate is supplied.

Any ideas about what I’m doing wrong? Big thanks in advance!

ETNyx

Those openssl test was made from same affected machine? Do you want to share your domain name that we can test your ssl from our location?

Also rigorously, you did this and this right?

xlx

ETNyx Many thanks for your response! Yea exactly, tested on the same machine and did both things. Sure, MAILCOW_HOSTNAME is vexx.steinert.io in my case.

ETNyx

Try to restart your mailcow stack for 993 (imap) NotAfter: Oct 26 20:14:04 2024 GMT for 443 (https) NotAfter: Jan 2 20:10:35 2025 GMT

xlx

Tried this several times, but just ran sudo docker restart again explicitly.

One thing I just noticed is that there is a difference in running the ‘expiry-dates.sh’ with and without sudo:

$ bash expiry-dates.sh expiry-dates.sh: line 4: ../mailcow.conf: Permission denied TLS expiry dates: Postfix: Jan 2 20:10:35 2025 GMT Dovecot: Jan 2 20:10:35 2025 GMT Nginx: Jan 2 20:10:35 2025 GMT

vs.

$ sudo bash expiry-dates.sh TLS expiry dates: Postfix: Oct 26 20:14:04 2024 GMT Dovecot: Oct 26 20:14:04 2024 GMT Nginx: Jan 2 20:10:35 2025 GMT

I’m using Ubuntu Server 24.04.1 LTS btw.

esackbauer

xlx One thing I just noticed is that there is a difference in running the ‘expiry-dates.sh’ with and without sudo:

You should not use sudo. Mailcow has to be installed and maintained with the root user, as explained here:
https://docs.mailcow.email/getstarted/install/#install-mailcow

ETNyx

First of all do not manage mailcow as normal or sudo user, allways use root

su
umask
0022 # <- Verify it is 0022

Second expiry-dates.sh most-likely load some variables from mailcow.conf in first run without sudo you got Permission denied so what exactly is expiring who knows??

Third, you are using external certificate right? So are you sure you combined your certificates and key and copy them to data/… like this right?

Edit: And again you need to be root (as my First) otherwise your cert and key may not be loaded and used old one (just a guess)

xlx

Oh damn. I missed the information, that it may not be run as a sudo user. I try to solve that. Big Thanks!

Regarding your third note, that’s my renewal script:
$ nano /etc/letsencrypt/renewal-hooks/deploy/001-renew-mailcow.sh #!/bin/bash cp /etc/letsencrypt/live/steinert.io/fullchain.pem /opt/mailcow-dockerized/data/assets/ssl/cert.pem cp /etc/letsencrypt/live/steinert.io/privkey.pem /opt/mailcow-dockerized/data/assets/ssl/key.pem postfix_c=$(docker ps -qaf name=postfix-mailcow) dovecot_c=$(docker ps -qaf name=dovecot-mailcow) nginx_c=$(docker ps -qaf name=nginx-mailcow) docker restart ${postfix_c} ${dovecot_c} ${nginx_c}

ETNyx

Seems like this great! I would check permission of those files in data/assets/ssl/ I would guess it should belong to root and some reasonable 600 (644) should be as chmod. (I do not use external cert so I can not check, sorry)

xlx

Hum.. how can I install and maintain it as root? Every file is recursively owned by root in /opt/mailcow-dockerized. I restarted the whole docker instance with root. I executed the ssl-copy script as root. Root has 0022 if I run umask. But if I run the following as root it doesn’t seem to get better 😅:

root$ bash expiry-dates.sh unable to load certificate 140512420431168:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE TLS expiry dates: Postfix: Oct 26 20:14:04 2024 GMT Dovecot: Oct 26 20:14:04 2024 GMT Nginx:

Am I missing something so fundamental? 😕

ETNyx

This seems your pem files are outdated check them something like openssl x509 -enddate -noout -in /opt/mailcow-dockerized/data/assets/ssl/cert.pem

xlx

root$ openssl x509 -enddate -noout -in /opt/mailcow-dockerized/data/assets/ssl/cert.pem notAfter=Jan 2 20:10:35 2025 GMT 🤔

Do the images have to be rebuilt to update the certificate?

esackbauer

xlx Do the images have to be rebuilt to update the certificate?

https://docs.mailcow.email/post_installation/firststeps-ssl/#force-renewal
Do a force renewal

xlx

Did it: acme-mailcow-1 | Fri Nov 1 15:57:17 CET 2024 - SKIP_LETS_ENCRYPT=y, skipping Let's Encrypt... And it changes nothing.

What I’ve noticed regarding the 140153327334720:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error:

openssl s_client -connect vexx.steinert.io:143 -starttls smtp results in “Didn’t find STARTTLS in server response, trying anyway…” while openssl x509 -enddate -noout -in /opt/mailcow-dockerized/data/assets/ssl/cert.pem shows the certificate.

esackbauer

xlx SKIP_LETS_ENCRYPT=y

Why did you disable it??

xlx

Because I’m using my own custom Let’s Encrypt certificate (same as the nginx webserver). So I want to use the same certificate for my webserver and mailcow. And the docu specified “mailcow must be available on port 80 for the acme-client to work”. That’s not the case for me, so I disabled the internal Let’s Encrypt handling from mailcow.

esackbauer

Ah sorry, missed that part.

But then, you can ignore the acme-mailcow-1 logs. The container is running but not doing anything.

How did you configure Apple Mail? IMAP or ActiveSync?
Are you sure all needed DNS names are included in the certificate? Is the certificate you copied a full chain, including the certificate, intermediate and LE root?

xlx

I just found out, that there was a folder vexx.steinert.io at /opt/mailcow-dockerized/data/assets/ssl/backups with the old cert.pem and key.pem. Those mailcow containers used that old certificate from that backup folder. After I deleted this folder everything worked fine and Mailcow finally supplied the new certificate. I don’t know why there was this backup folder and how it was created. But well, the deletion fixed my problem, big thanks for your help! 😊