Problem with mail account sign in from google. Copy this domain's SSL certificate as the default for the chosen service cannot save

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

Status: 
Active

Comments

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.

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.

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

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?

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

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.

Ilia's picture
Submitted by Ilia on Tue, 01/05/2021 - 15:55

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.

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.

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.

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.

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.