Gmail LS Negotiation failed
I have been having issues with Gmail and sending mail as over the last few days. When sending email as (from my domain domain.org) I get a return email stating "TLS Negotiation failed, the certificate doesn't match the host. " Now I have been sending mail as through Gmail with multiple accounts for a very long time.
So I go into accounts and import and any of my accounts adding, or updating passwords I get an error saying Server returned error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0"
So here is what I have tried as settings - I typically have used the domain name as the smtp host - domain.org or mail.domain.org I have also tried the host.com and get the same message. I have used both SSL and TSL ports 465 for SSL and 587 TLS.
So with troubleshooting, I added these accounts to outlook (the app) and Bitdefender through up an error as well saying "OUTLOOK.EXE attempted to establish a connection relying on an unmatching security certificate to domain.org. We blocked the connection to keep your data safe since the used certificate was issued for a different web address than the targeted one" and I went ahead and added the exception and outlook did give me "
The server you are connected to is using a security certificate that cannot be verified. The target principal name is incorrect. I believe that was using the domain name. Now in outlook if I use the hostname I get 0 error. But if I do that in Gmail I get error.
Any thoughts? My data center is out of ideas as well.
-
Going to add to this and this is very very strange. If I go into a Gmail account I have that doesn't get used much at all and add these to it as send mail as using TLS port 567 I have 0 issues getting it to go through. Maybe this is just a Google issue? 0 -
Yes Gmail recently implemented this and we've seen a number of clients running into it. I'm not clear if Gmail is not supporting sni certificates for mail service but we've resolved this by using the server's hostname as the incoming and outgoing mail servers. This assumes you have a valid resolving hostname. 0 -
Ya I have even had the data center double-check my hostname resolver and all. I can get the email to work if I go unsecured port 25 though :( 0 -
I would check manage service ssl certificates and verify there are valid certificates installed. If your hostname resolves, it should have them. 0 -
The target principal name is incorrect. I believe that was using the domain name. Now in outlook if I use the hostname I get 0 error. But if I do that in Gmail I get error.
This lends to the theory that @GOT had that the site doesn't have a valid certificate. When this occurs the certificate for the hostname is used instead.0 -
Certificates validate and return back just like they are supposed to. everything directs like it has for the past 10 years. been running servers for past 30 years and ya this has me stumped. I am just thinking its something google is doing considering I can go to one of my less-used Gmail accounts and it works fine for those same domain names and email addresses with 0 errors. 0 -
I have been having issues with Gmail and sending mail as over the last few days. When sending email as (from my domain domain.org) I get a return email stating "TLS Negotiation failed, the certificate doesn't match the host. " Now I have been sending mail as through Gmail with multiple accounts for a very long time. So I go into accounts and import and any of my accounts adding, or updating passwords I get an error saying Server returned error: "TLS Negotiation failed, the certificate doesn't match the host., code: 0" So here is what I have tried as settings - I typically have used the domain name as the smtp host - domain.org or mail.domain.org I have also tried the host.com and get the same message. I have used both SSL and TSL ports 465 for SSL and 587 TLS. So with troubleshooting, I added these accounts to outlook (the app) and Bitdefender through up an error as well saying "OUTLOOK.EXE attempted to establish a connection relying on an unmatching security certificate to domain.org. We blocked the connection to keep your data safe since the used certificate was issued for a different web address than the targeted one" and I went ahead and added the exception and outlook did give me " The server you are connected to is using a security certificate that cannot be verified. The target principal name is incorrect. I believe that was using the domain name. Now in outlook if I use the hostname I get 0 error. But if I do that in Gmail I get error. Any thoughts? My data center is out of ideas as well.
hello i also face this same difficulty, i have been trying to send a mail from my gmail using my website webmail which i linked since a month ago its not working, this issue is quite new. PLEASE could any one help me out on this!!!!!!!!!!!!!!!!!!0 -
Certificates validate and return back just like they are supposed to. everything directs like it has for the past 10 years. been running servers for past 30 years and ya this has me stumped. I am just thinking its something google is doing considering I can go to one of my less-used Gmail accounts and it works fine for those same domain names and email addresses with 0 errors.
How did you do that work please, I really need to solve this issue0 -
Now I'm checking my own account in Gmail that I have set up. Incoming set as always use a secure connection and port 995 then when I check "Send mail as" Send mail as those accounts and I see them going through without issue. I am confirming the TLS connection in /var/log/exim_mainlog as well, they're using:
X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128
Because Bitdefender also gives a similar error it's doubtful it's just Gmail's issue. Can you PM me the domain name experiencing the issue?
Hey please, could you help me by any chance work this out??0 -
I'm having the same issue. I was able to send emails earlier this week, but it stopped working as of Wednesday. I've been in support chats with GoDaddy and they keep changing things up (worst CX) without telling me and then the next person changes them again. I've tried all ports and mail.domain.ca vs domain.ca. I just tried setting up a new email to see if it was a one-off, but the same issue exists with the test email address. 0 -
I too am having the same issue, I've been setup this way for years. All of a sudden I started getting the same exact issues. Do we have a solution yet? I read the thread but didn't see anything definitive. I'm with Sosa237 on understanding it at more depth. I also do not believe my certificate ever matched. ***Seems to be a GMAIL issue: 0 -
Right now it appears that my problem is attached to running ASSP. I have ASSP Deluxe through the GRscripts ASSP Deluxe interface. Disabling ASSP Deluxe entirely got me back up and running. I am emailing back and forth with the developer troubleshooting now. So maybe others are running additional protection scripts causing the mismatch issue. Ill update this when I get this fixed entirely. But so far, my issue is with ASSP Deluxe and disabling it entirely worked. 0 -
Thanks for the note on ASSP @PDW could be that folks running MailScanner as well are having an issue, though unsure. Also, thank you @lorizb for sharing the Gmail thread I looked for one initially but was unable to find one. A lot of folks in that thread are changing their SMTP server setting. So I'd like to ask all of you experiencing this issue to do the following: - Determine what your SMTP server setting should be. This can be found in cPanel>>Email>>Email Accounts>>Connect Device - Typically this is mail.yourdomain.tld
- Go to Gmail>>Setting>>Accounts and Import -> Send Mail As -> Edit Info (next to the account you're modifying) - Ensure the settings on the first screen are correct (most likely you won't need to change those) - Click Next Step - On this page you'll do the following: SMTP Server: mail.yourdomain.tld (or whatever you found) Port: 587 Username: user@yourdomain.tld Password: your email password Select Secured connection using TLS And let me know if this works0 -
Hello everyone! I did the test verifying the SMTP as @cPanelLauren recommends and it was not solved. Be something in the settings in my DNS? It works for some and not for me so I want to discard all the options. I appreciate your help KD 0 -
What is the output you get @KD-digital? Did you read the Gmail thread on this that's linked in one of the above posts? 0 -
No lack for me too 0 -
@cPanelLauren My cpanel host is companyname.com:2082. These are the instructions given to me by cpanel's 'connect devices' section: I then enter these into Gmail using SSL: "TLS Negotiation failed, the certificate doesn't match the host., code: 0" And then when using TLS, it takes a long time and appears to timeout: We're following the instructions, but it just doesn't work. Hopefully you can see even with blurring, the addresses are the same in the boxes. What do we do? 0 -
@sgpascoe The issue in this screenshot is pretty clear, you're using port 465 and trying to connect with TLS. I specifically noted you should be using port 587 and TLS 0 -
@sgpascoe The issue in this screenshot is pretty clear, you're using port 465 and trying to connect with TLS. I specifically noted you should be using port 587 and TLS
@cPanelLauren My apologies, I missed that, I was going by the instructions provided by the Cpanel connect devices page. Using 587 on TLS has the same result:0 -
Is there anyone who can confirm this change to port 587 has worked for them? We have a bunch of clients with this issue, but of course they aren't very savvy.. I don't currently have a test account to test with. If someone can confirm I can let clients know what to change. 0 -
Nope, it was an effort to see if it worked. My account is able to use Gmail without issue so It's not affecting everyone, but from what I was seeing in the google thread here: it looked like the key was in the server name being used. If the name doesn't exist or if it is associated with the hostname which uses a different certificate this is going to fail, if you're using a self signed certificate this will fail. If the Server name i.e., mail.domain.tld is not covered under the SSL this will fail. This is a result of stricter security in place for google. This is not something that cPanel has any control over. It's best explained here: 0 -
Hey guys so just updating on this thread, should be my final. So I got this resolved and it was my ASSP Spam filters that was causing the issue. I use GRscripts ASSP Deluxe and he helped me nail it down. I have been using it for a while now and I had a version 1.9.9 of ASSP (even though his interface showed updated it wasn't) there was version 2.6..... so I had to do a big update on ASSP and after following all of his steps I was back to working just fine and figured it all out. So maybe with others check to see what the mailscanner, ASSP etc... is using for the SSL Cert and working with SNI 0 -
Nope, it was an effort to see if it worked. My account is able to use Gmail without issue so It's not affecting everyone, but from what I was seeing in the google thread here: it looked like the key was in the server name being used. If the name doesn't exist or if it is associated with the hostname which uses a different certificate this is going to fail, if you're using a self signed certificate this will fail. If the Server name i.e., mail.domain.tld is not covered under the SSL this will fail. This is a result of stricter security in place for google. This is not something that cPanel has any control over. It's best explained here:
0 -
What is the output you get @KD-digital? Did you read the Gmail thread on this that's linked in one of the above posts?
Same error: Still no solution from godaddy? Thanks!0 -
Hello cPanelLauren, any real solution to the problem? So far the problem seems unsolved!
No, this is a change on Gmail's end, not ours. you can read through the linked threads to Gmail as well as the other user's suggestions as to what has worked for them.0 -
Hello People! They found the solution to this problem! Follow the link: SOLVED: TLS Negotiation failed, the certificate doesn't match the host., code: 0 -52-31.png">64833 0 -
Hello, While I appreciate that @WagnerCoelho33 the solution provided there is not a real solution. The problem is not on GoDaddy's end, this is a result of a change that Gmail made to strengthen their security. The solution from what I see right now is to ensure that there is no certificate mismatch on any of the properties associated with the hostname or MX record. You should not use the hostname as the SMTP server this incorrectly bypasses the domain-specific certificate if one exists. Furthermore, many using this found that they had the hostname in prior and it no longer works. 0 -
Hello, While I appreciate that @WagnerCoelho33 the solution provided there is not a real solution. The problem is not on GoDaddy's end, this is a result of a change that Gmail made to strengthen their security. The solution from what I see right now is to ensure that there is no certificate mismatch on any of the properties associated with the hostname or MX record. You should not use the hostname as the SMTP server this incorrectly bypasses the domain-specific certificate if one exists. Furthermore, many using this found that they had the hostname in prior and it no longer works.
Okay, I removed the responsibility for the problem from my post! Enjoy my provisional solution!0 -
@PDW I'm wondering if you'd be willing to share what settings you used in Gmail to get this working with ASSP. I've got a client (domain2.com) on my server (primary account is domain1.com) that uses Gmail for all of their email accounts on my server. ASSP is setup on my hostname (admin.domain1.com). The client has been using admin.domain1.com as their server setting for Gmail SMTP for years without issue. But now I'm second guessing if they should be continuing to use this, or switch this what cPanel says they should be using, which is mail.domain2.com. FWIW, neither of these, nor trying ports 465 and 587 are working for them. I did just enable SNI for ASSP, but I'm not sure if this will help 0
Please sign in to leave a comment.
Comments
34 comments