Enviorement. Mailserver in multiserver system, installed postfix, dovecot and roundcube Thunderbird on linux mint notebook all systems lastest versions debian 10, mint 20.x latest patches, lastest ISPConfig Version Sending mail from thunderbird connected to a mailbox on the mailserver, gives me a notice the cert for smtp has expired. Is is a letsencryp cert but expired last year. The webserver running shows a valid and not expired letsencrypt cert. So I look for a solution and found https://community.letsencrypt.org/t...tificates-with-postfix-dovecot-software/94689 and other similar. Following this works for dovecot, but in postfix thunderbird tells me postfix can not process mail in case of internal problem, Sending mails from gmail to my account were not delivered until I unmade changes. I tried some other similar solutions but allways the same. need help, hint Thank you
ISPConfig sets dovecot, ftp and postfix to use the same host certificate as the panel uses. This should just work. Is this a system you just now installed? Is it a multiserver system where postfix is running on another host? Have you generated certificate manually from the command line? Maybe start with this:https://www.howtoforge.com/community/threads/please-read-before-posting.58408/ If the webserver has valid certificate, the problem is just that postfix is configured to use some other certificate. Try Code: ispconfig_update.sh --force , let it make new certificate and force reconfigure services. That might help. If not, dig deeper.
Does the server uses certbot or acme.sh as the LE client and have you added a website with the hostname of the server on that mail server?
Since this is a multi server as you said, did you mean the web server LE certs should be the same as the mail server because they are in one same server? By the way, the solution you referred to might not be suitable in the case of ISPConfig server.
everything is on the same server, with the same name. i.e http://mail.domain.tld/webmail points to roundcube gets the certificate from letsencrypt, then dovecot, them postfix hostname mail.domain.tld. I noticed dovecot and postfix certs cam originaly from the ISPConfig installed cert, but there is no ISPConfig panel on that server. What I changed was replaceing the path to the certs to the letsencrypt certs, i.e to /etc/letsencrypt/live/mail.domain.tld/fullchain.pem respectiv privkey.pem. that worked fine for dovecot, testing port 993 and 995 showed me the same actual cert as roundcube, but setting the same path in postfix give me the problem. The system works since years was first installed on debian 9 and updated to debian 10 moth ago and runs fine so far the server uses certbot
I think if mail.domain.tld is the server only hostname FQDN then, using ISPConfig installer via force update may fix your problem as suggested by @Taleman above but I'd suggest using git-stable as @Jesse Norell has some new fixes for its symlinks. However, if the domain is not the server only hostname FQDN then, @Th0m tip and trick on the same should be a better guide for you.
OK thank you I will try this next weekend, On workdays I will not experiment as the mailserver is used by some business customers who count on the function of the mailserver
I tried ispconfig_update.sh --force, now postfix and dovecot points to the same expired certificate as before. The webserver certificate used by roundcube is still the valid certificate by letsencrypt. I understand that ISPConfig lets dovecot and postfix point to the ISCConfig certificate, but this is not updated even it is a letsencrypt cert. So even if I can get postfix point to the valid cert of the webserver as i manged with dovecot, the next ISPConfig will undo my changes. So one solution, in my view, might be to get a letsencrypt certificate for ISPConfig and to manage that this will be used by the webserver too and that this configuration will not be changed by any ISPConfig update. Regards Rainer
If you have at some point manually from command line renewed the certbot certificates that has broken ISPConfig setup and it no longer handles the certificate renew correctly. If this is the case, remove the wrongly generated certificates to give ISPConfig a clean slate. Then certificates and renewal of them should start working.
Can not remember doing this. I even wonder from wehre the ISPConfig Certificates come, the server never had been ans ISPConfig Master Server nor had been the the ISPConfig panel installed. Is was created as a mail server in a multiserver system, following the lates ISPConfig 3 manual (which is quite old in the meantime). So in my opinion there was no need to install a certificate for ISPConfig anyway. Regards Rainer
ISPConfig installer from 3.2 version do have option to create SSL certs during install or update even on its mail server but you have to choose that option. I think @Taleman is correct to suggest removal of any LE certs you create manually for your ISPConfig mail server (after a backup made of course) and let the ISPConfig installer create a clean one for it.
As you have a current certificate in the web server there, remove the cert files/symlinks under /usr/local/ispconfig/ssl/ and create symlinks pointing to the letsencrypt cert files your web server uses. I don't know what you have setup for postfix and dovecot certificate paths, but those can either point to the /usr/local/ispconfig/ssl/ locations, or they can likewise be symlinks to the web server's cert files. Restart postfix and dovecot and you should have a current certificate for both. Then when you update ISPConfig, simply do not choose to generate new certificates (which should be the default) and it won't change what you have in place.
Why the best is for you to remove the old self obtained LE certs and apply new ones via ISPConfig installer during force update is very obvious i.e. because you will want all related services to restart automatically upon any future renewals which is done by ISPConfig LE pre and post renewal script, only if you use ISPConfig to create the mail server LE certs (which extend to all other services) for you. This will not work automatically, in my personal notes if you are using acme.sh, since it only install the LE certs in one place i.e. the ISPConfig SSL folder and upon creating any website for your mail server that has the same name with its hostname FQDN, it will then be moved to install at its web SSL folder. This breaks a lot of things but so far that I know nobody raise this acme.sh problem as an issue or fix this as yet.
All letsencrypt Certs are done by ISPConfig. But I found a solution with symlinks to the lets encrypt certs. And I tried a fore update and it still works, so for the moment ist solved Thanks for help Rainer
