I suspect the mail client is trying to connect to a domain name that is different from how the mail server identifies itself. Postfix does not (in the most commonly deployed versions) support SNI for domain-based virtual hosting. You need your mail clients to connect to whatever domain you have chosen for Postfix to use for TLS. A domain name mismatch on the certificate would cause a TLS error.
Edit: To be clear, it’s not directly caused by the user@domain.tld name, but it may be caused by the mail client making an assumption about what server name to connect to based on the domain after the @.
Interesting… in the past, usernames on my servers were made as name.domain, not name@domain.com… and the name.domain ones are still working as gmail ‘send as’ without any problems.
What could I have changed that changed the way domain names are created? Or could an update have changed that…?
It’s not “how domains are created”, it’s how your mail client is communicating with the server (at least, if my guess above is correct, which is still up in the air).
Certificate 1 of 1 in chain: Cert VALIDATION ERROR(S): unable to get local issuer certificate; unable to verify the first certificate This may help: What Is An Intermediate Certificate So email is encrypted but the recipient domain is not verified
I’m savvy about quite a bit stuff online, but these email networks, connections and authentications confound me.
Hello christophera In addition to Joe’s contributions above. I suggest this, if not already done, using Virtualmin, add a valid CA-Signed SSL certificate on the Virtual Server(s) which is sending the outgoing email messages. And using Webmin activate TSL appropriately.
Detail
Below is the same answer as above but with details for those interested, or for newcomers.
Many of our clients at Ubertus faced the same challenge starting early April 2020. The source of this challenge is that as of April 2020, Gmail changed their requirements on outgoing email messages using Gmail. As below:
Required
CA-signed SSL certificate
With valid TLS
Rejected
Self-signed SSL certificate
Without valid TLS
Assumptions
Assumes a CA-signed SSL certificate such as, but not limited to, free & secure Let’s Encrypt certificate, or any CA-signed certificate to your liking from a Certificate Authority (CA). I suggest Let’s Encrypt CA because it has stronger security & stronger privacy. Adding a Let’s Encrypt certificate is located at « Virtualmin —> Server Configuration —> SSL Certificate —> “Let’s Encrypt” horizontal tab ». Documentation.
Assumes TLS version 1.2 (TLSv1.2) or more recent is suggested. As of 2018 TLSv1.1 or TLSv1.0 are not fully secure. TLS needs to be both activated & appropriately configured.
Assumes activating TLS is located at « Webmin —> Servers —> Postfix Mail Server" —> SMTP Client Options »
“Use TLS for SMTP connections” first line: Yes
“Use TLS for SMTP connections” second line: If requested by client.
Note: Or any other appropriate setting to your liking. If you set to “If requested by client” and configure every single smtp client (including roundcube) to use TLS you will only send secure email but you can still receive from servers that won’t send you secure email.
Assumes as of April 2020 Gmail require a SSL certificate for outgoing email. Source.
Assumes that the “TLS Negotiation failed” error is presently random because Gmail are in progress of implementing their new requirement. They have lots of mail servers behind their load balancers. So which server handles each outgoing email message is random. Thus random “TLS Negotiation failed” error.
Assumes all of the above is for Debian 10 & Postfix 3.4.7
Alternatives
Feel really free to use Gmail. For those not familiar with the security & privacy risk with Google’s products, including but not limited to Gmail, according to Caroline Donnelly & Wired, there is a significant security & privacy risk with Gmail. Because of the 2018 CLOUD Act & the 2001 Patriot Act, for stronger privacy & security I suggest any email provider to your liking other than Gmail, and with their head office outside the USA territories. Alternatives to Gmail. Most people at Google are really friendly But the CLOUD Act & Patriot Act are a significant security & privacy risk for your data
Thank you so much, had no idea that GMail had changed things.
Question… I have a number of domains that I manage with virtualmin on this server.
Under the ‘Let’s Encrypt’ tab - it looks like I can add additional domain names. Can I add all the domains on the server, sample.com, example.com, etc, com, all under one cert? I thought it used to be that you had to have a separate ip address for each domain covered by a cert, is that no longer true?
Ok, I see, I get certs for each domain individually through Virtualmin, got it
Ugh… because things can never be simple… some of the domains I have are mail only, and to add a cert through Virtualmin, I have to enable the website. No problem there, the dns points to the other server with the website on it.
Uh, but Virtualmin adds a file that Let’s Encrypt looks for to validate the domain… but the website it is trying to access for validation is on a different server… hmmm…
You’re making this way too complicated (impossible, actually).
Postfix (in the versions most people are running) doesn’t support SNI, anyway, so you can’t use a bunch of different mail names on the same IP with TLS. You need to settle on one mail domain, get a valid certificate for it, and use it for all outgoing mail (the From: doesn’t matter…we’re just talking about the outgoing server name here).
Yep Email networking and authentication always gets me going in circles.
OK, I have it all set up on one mail.domain and that’s working now. Just set that up with a site so I could validate the Let’s Encrypt cert and that worked (before I was using Cloudflare’s virtual ssl and a self-signed cert). Tested with different email addresses on different domains with mail.domain as the smtp server, and they are working Is that what you meant?
You’re welcome Chris. Congrats on resolving your challenge. Enjoy
had no idea that GMail had changed things.
Same here. We learned it from our business network and from end-users No notice from Google’s Gmail The Ubertus team did a deep Lord of the Ring type quest to find the source of this challenge
@christophera I agree with @Joe that, when realistic & possible, it’s usually much easier, faster, cheaper to use one dedicated Virtualmin Virtual Server (domain) for all your outgoing mail from all your domains. For example, mail.domain.tld or any naming to your liking. Which you successfully did above.
Both Virtualmin & Webmin have very good, easy, and automated support for Let’s Encrypt. But there is an initial learning curve. We all went through it
Like many Ive been blissfully using gmail to send emails from gmail using their send as alias feature - since this TLS issue come to light Ive been getting the ‘TLS Negotiation failed, the certificate doesn’t match the host error’ but after adding a CA signed SSL cert to my main domain covering mail.domain.tld and copying that cert to postfix I still cant get gmail to connect to mail.domain.tld on port 587 using TLS. I’ve checked the ‘use TLS for SMTP connections’ in webmin–>servers–>postfix mail server -->STP client options as suggested and restarted postfix but still no joy.
I wondered if it may be due to the TLS version being used. Is the following line in the postfix config correct or does this require updating?
If you haven’t already, for the secured domain, try going to virtualmin > server config > ssl > and hit the ‘copy to postfix’, then retry gmail and see if that does the trick,
In addition to Joe’s contributions above. I suggest this, if not already done, using Virtualmin, add a valid CA-Signed SSL certificate on the Virtual Server(s) which is sending the outgoing email messages. And using Webmin activate TSL appropriately.
