I have enable the "Send mail as:" option for some clients in order to be able send mail from their domain through gmail. I had some complains that they got error message while they to use this function. The message they get is
From Mail Delivery Subsystem
The response was: TLS Negotiation failed, the certificate doesn't match the host.
Strange thing is that when i go to Virtual Panel and press the buttons in order to copy domain's SSL certificate as the default for the chosen service (attached photo) problem get solved but only for some hours. When the problem returns i check again Virtualmin and buttons appear again and i have to click again in order to solve the problem. It seem that system cannot keep these settings but i cannot figure why :-/
Any help will be appreciated.
Thank you
Comments
Submitted by alstam on Sun, 04/26/2020 - 05:40 Pro Licensee Comment #1
Also another issue that is strange is that despite all buttons after click disappear the button copy to Dovecot stays there. This is not necessary a problem but just asking.
Submitted by JamieCameron on Sun, 04/26/2020 - 11:54 Comment #2
Do your domains have their own private IP addresses? That would be needed to setup a private SSL cert that is used for SMTP for just that domain.
Submitted by alstam on Sun, 04/26/2020 - 11:58 Pro Licensee Comment #3
I am not sure if i understood what do you mean. No i don't think that have their own private ip. I don't know how to setup this. All domains have my server's ip address . Same setup i had while using cpanel. What is your recommendation?
Thank you for supporting me
Submitted by JamieCameron on Sun, 04/26/2020 - 16:32 Comment #4
I might be looking at the wrong problem then - Can you post the full contents, including headers, of the email in which you saw that "The response was: TLS Negotiation failed, the certificate doesn't match the host." error?
Submitted by alstam on Sun, 04/26/2020 - 16:46 Pro Licensee Comment #5
This is not an email. I am trying to set up gmail to send mail as one of my addresses. If i select port 25 and unsecured there in no problem. When i select ssl port 465 i receive the following message
Authentication failed. Please check your username/password.
Server returned an error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0"
If i click buttons at the attached photo for the selected domain problem temporary get solved.
But now i notice that when i click buttons for one virtual host then the other virtual host i set up before has again buttons available so i think that your previous answer has a point.
But i don't' know what do you mean if every domain has it's own ip address, how can i setup this? Sorry if i don't explain very well
Submitted by soydemadrid on Tue, 01/05/2021 - 04:38 Pro Licensee Comment #6
I also now have this problem - it seems to be something recent that Gmail have changed possibly?
I get the same error on accounts that were previously working with Let's Encrypt certs and email domains in Google Mail.
First of all, if you don't have
certbot
package installed, install it and re-request all certificates (possibly a wildcard certificate, if DNS hosted locally), at least for those domains that have issues.Yes, when you click those Copy to .. buttons for one of the domains, this domain's certificate is being copied as a default service (Postfix in particular) certificate but considering you're running CentOS 7 and Postfix doesn't have SNI support, what you could do, is to create one large default certificate with all hosted domains placed into it.
The problem is, when you have a certificate issued for the particular domain, and then you click Copy to .. button, this certificate is correctly being used when you connect to this particular domain, however, if a user connects to mail.user-domain.com, then you get an error you're getting -- which means the certificate that is being presented (default) doesn't contain a domain that is currently being used.
The work-around would be, as already mentioned earlier, to create one certificate which would contain alternative names for all hosted domains (virtual servers), so then users could connect to your server using their domain names, without getting an error. Another solution would be is to setup a certificate for mail.yourhostname.com domain and make sure that your users use only mail.yourhostname.com to fetch their mail.
Additional but unrecommended solution would be is to upgrade to Postfix 3.4+ which supports SNI.
We would recommend from SSL Certificate > Service Certificates page to first disable Dovecot domain certificate enabled and then re-enable it, to have Dovecot records regenerated, dropping old ssl_ca records.