Community Discussions and Support
GMail: Authentication failed. Please check your username/password. Server returned error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0"

I already have my own smtp server, which is the one I'm trying to use.  I also have SPF, DKIM, and DMARC fully set up.  I also run my own DNS server.  I've actually already left Gmail now.  I'm switching my users over to Thunderbird as an email client, and using Mercury as the server.  So far so good.  By the way, across different Gmai laccounts, the exactly same settings are garnering different results.  Something in Gmail's sending is truly broken right now.  It's intermittent at best.

I already have my own smtp server, which is the one I'm trying to use.  I also have SPF, DKIM, and DMARC fully set up.  I also run my own DNS server.  I've actually already left Gmail now.  I'm switching my users over to Thunderbird as an email client, and using Mercury as the server.  So far so good.  By the way, across different Gmai laccounts, the exactly same settings are garnering different results.  Something in Gmail's sending is truly broken right now.  It's intermittent at best.

Heads up all:

 

Gmail made a policy change, which appears to be broken.  It now won't allow me (and many others) to send from Gmail using my Mercury mail server.  They're rolling out this change slowly, so not all accounts are affected yet.

 

For the accounts that are affected, the user will receive a bounce message that says:

TLS Negotiation failed, the certificate doesn't match the host. 

 

If you try to update your SMTP settings for the account within your Gmail, it will give the following error:

Authentication failed. Please check your username/password. Server returned error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0"

 

I've tried recreating my certificates with and without sub-domains, and have also tried every possible permutation of using or not using sub-domains in Gmail's "SMTP Server" box, using 465/SSL, using 587/TLS, and even trying 465/TLS and 587/SSL.  Nothing has worked and it gives the same error regardless.

 

I'll let you know if I find a solution. 

 

<p>Heads up all:</p><p> </p><p><span style="font-size: 10pt;">Gmail made a policy change, which appears to be broken.  It now won't allow me (and many others) to send from Gmail using my Mercury mail server.  They're rolling out this change slowly, so not all accounts are affected yet.</span></p><p> </p><p>For the accounts that are affected, the user will receive a bounce message that says:</p><p><b><span style="color: rgb(34, 34, 34); font-family: monospace; font-size: 12.8px;">TLS Negotiation failed, the certificate doesn't match the host.</span><span style="font-size: 10pt;"> </span></b></p><p> </p><p>If you try to update your SMTP settings for the account within your Gmail, it will give the following error:</p><p><b>Authentication failed. Please check your username/password. Server returned error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0"</b></p><p> </p><p>I've tried recreating my certificates with and without sub-domains, and have also tried every possible permutation of using or not using sub-domains in Gmail's "<span style="background-color: rgb(255, 247, 215); font-family: arial, sans-serif; font-size: 12.8px; text-align: -webkit-right;">SMTP Server</span><span style="font-size: 10pt;">" box, using 465/SSL, using 587/TLS, and even trying 465/TLS and 587/SSL.  Nothing has worked and it gives the same error regardless.</span></p><p> </p><p>I'll let you know if I find a solution. </p><p> </p>

I am truly stumped.  I've think I've tried everything numerous times now.  Regenerating the cert in a million different ways didn't help, neither did changing everything to the same domain rather than using a different subdomain for my mail server.  The problem is steadily affecting more Gmail accounts.

I am truly stumped.  I've think I've tried everything numerous times now.  Regenerating the cert in a million different ways didn't help, neither did changing everything to the same domain rather than using a different subdomain for my mail server.  The problem is steadily affecting more Gmail accounts.

I tried creating a certificate by CSR (signing it with my CA) instead of a self-signed, but it made no difference.  I even tried using a certificate bundle to include the CA certificate with it, but no joy.

I tried creating a certificate by CSR (signing it with my CA) instead of a self-signed, but it made no difference.  I even tried using a certificate bundle to include the CA certificate with it, but no joy.

[quote user="Tim W Young"]I tried creating a certificate by CSR (signing it with my CA) instead of a self-signed, but it made no difference.  I even tried using a certificate bundle to include the CA certificate with it, but no joy.[/quote]

Isn't this the dreaded OAuth2 issue, once again in a different disguise?

<p>[quote user="Tim W Young"]I tried creating a certificate by CSR (signing it with my CA) instead of a self-signed, but it made no difference.  I even tried using a certificate bundle to include the CA certificate with it, but no joy.[/quote]</p><p>Isn't this the <a mce_href="/forums/thread/51644.aspx" href="/forums/thread/51644.aspx">dreaded OAuth2 issue</a>, once again in a different disguise? </p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

Unfortunately, as far as I can tell, it's a new issue.  Btw, I also tried enabling "less secure apps" and that didn't make any difference.

Unfortunately, as far as I can tell, it's a new issue.  Btw, I also tried enabling "less secure apps" and that didn't make any difference.

I suspect that Gmail is no longer respecting the "less secure apps" option. 

I think (unconfirmed yet) that 2FA is going to have to be enabled on Gmail which will then allow the generation of an app password to use on Mercury.  AFAIK, the app password option is still working.

<p>I suspect that Gmail is no longer respecting the "less secure apps" option.  </p><p>I think (unconfirmed yet) that 2FA is going to have to be enabled on Gmail which will then allow the generation of an app password to use on Mercury.  AFAIK, the app password option is still working. </p>

Incoming/imap is working all right,  It's the outgoing/smtp.  When you set your google account to send using your own server, the less secure apps feature doesn't have any effect.

It seems that you need to actually have a paid certificate from a common CA, which seems ridiculous to me.  I don't understand why we should be forced to introduce an expensive third party to tell my users that they can trust me, when they already know me and I can issue them a cert.  I don't know why google didn't just do something like allow us to install our own certificate to be used for the sending for that specific account, so we could either use a common CA, or our own.

At this point I'm getting the clear feeling that google really doesn't give a damn about whoever is affected.  They're just making authoritarian decrees.  This is like the oauth2 situation, where they're recklessly breaking things as they go, but they have their 'vision'...  (As you can probably tell, I'm a bit frustrated with them...)

At this point I'm working on leaving Google entirely.  With how they're behaving, I'm not even going to promote their other services anymore.

<p><span style="font-size: 10pt;">Incoming/imap is working all right,  It's the outgoing/smtp.  When you set your google account to send using your own server, the less secure apps feature doesn't have any effect.</span></p><p>It seems that you need to actually have a paid certificate from a common CA, which seems ridiculous to me.  I don't understand why we should be forced to introduce an expensive third party to tell my users that they can trust me, when they already know me and I can issue them a cert.  I don't know why google didn't just do something like allow us to install our own certificate to be used for the sending for that specific account, so we could <span style="font-size: 13.3333px;">either </span>use a common CA, or our own.</p><p>At this point I'm getting the clear feeling that google really doesn't give a damn about whoever is affected.  They're just making authoritarian decrees.  This is like the oauth2 situation, where they're recklessly breaking things as they go, but they have their 'vision'...  (As you can probably tell, I'm a bit frustrated with them...)</p><p><span style="font-size: 10pt;">At this point I'm working on leaving Google entirely.  With how they're behaving, I'm not even going to promote their other services anymore.</span></p>

It seems that the sending of mails is becoming more and more restricted and complicated. But in times of spam the hurdles have to be raised more and more.
In the past days we had problems with "Error 554 Transaction failed", where mails that used to go out without problems are now rejected.
In this context I have also dealt with SPF, DKIM and DMARC. These are additional DNS records, with which the receiving MX server can check, if the mail was sent from the correct MX server of the sender's domain. And some mail servers may reject mails if the SPF record is not correct.
If you can't send mails via Gmail anymore, just look for another SMTP server. For example, we have been using the "Mailjet" SMTP service for quite a while, just only for sending of mails without changing our ISP Mailboxes or email addresses. There you have to register, but if you have less amount of e-mails per month, the service is for free. From there you can also directly adjust the SPF record of your home domain located at your domain registrar.

It seems that the sending of mails is becoming more and more restricted and complicated. But in times of spam the hurdles have to be raised more and more. In the past days we had problems with "Error 554 Transaction failed", where mails that used to go out without problems are now rejected. In this context I have also dealt with SPF, DKIM and DMARC. These are additional DNS records, with which the receiving MX server can check, if the mail was sent from the correct MX server of the sender's domain. And some mail servers may reject mails if the SPF record is not correct. If you can't send mails via Gmail anymore, just look for another SMTP server. For example, we have been using the "Mailjet" SMTP service for quite a while, just only for sending of mails without changing our ISP Mailboxes or email addresses. There you have to register, but if you have less amount of e-mails per month, the service is for free. From there you can also directly adjust the SPF record of your home domain located at your domain registrar.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft