Consider a scenario in which you’re trying to do the right thing by ensuring that authenticated SMTP client connections to your Exchange server are protected by TLS encryption. Most commonly this will be when you have IMAP or POP clients configured with the Exchange server (or a DNS alias that points to the Exchange server) as the SMTP server for sending email.
If the client tries to authenticate over an unencrypted connection, a message is received with words to the effect of:
The outgoing server (SMTP) mail.exchangeserverpro.net does not support the selected authentication method.
After Googling around you learn that your SMTP client should use STARTTLS in order to authenticate securely. Here’s an example of how that is configured in Mozilla Thunderbird’s outgoing server settings.
Notice also the use of port 587. Exchange servers are pre-configured by setup with a receive connector that is designed for use by SMTP clients, named “SERVERNAMEClient Frontend SERVERNAME”. This is the port and connector that you should be using for your authenticated SMTP clients.
When you next attempt to send an email you get a different error. Depending on the email client you may get a certificate trust warning, a prompt to add a security exception to trust the untrusted certificate, or it may just fail completely with a certificate error. In all cases, clearly something is still not right.
The solution here is in the configuration of the receive connector that authenticated SMTP clients will be connecting to. Even though you have enabled a valid SSL certificate for SMTP, the connector needs to be configured with the “TLS certificate name” that you want to use. The first time I ran into this problem I found lots of articles and blog posts telling me that was the solution, but none of them told me how to actually configure that. And if you look at the Set-ReceiveConnector documentation, you still get confusing (and wrong) advice.
The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer value is found in the certificate’s Issuer field, and the Subject value is found in the certificate’s Subject field. You can find these values by running the Get-ExchangeCertificate cmdlet.
The above would probably be more useful if it provided an example, but more importantly, the “[I]” and “[S]” are not correct. If you try to use them, your Set-ReceiveConnector command will fail.
Here’s an example of using the correct syntax for TlsCertificateName. First, determine the thumbnail value for the certificate you want to use. In this example I’m going to use my wildcard certificate, which is already enabled for SMTP.
[PS] C:\>Get-ExchangeCertificate
Thumbprint Services Subject
---------- -------- -------
4A4B66E94A9195FA3344E34E01E6698C44C0A639 ....... O=Microsoft, OU=Microsoft Monitoring Agent, CN={5B5FCD1B-5085-4...
D8C33B1E0FDFE180920C5CEED0612B95269FA1E7 IP.WS.. CN=EX2016SRV2
31E5D6D7E6BD77FC20FA4F490983C6945631CB6C ....... CN=WMSvc-EX2016SRV2
DE67EC3C8D679AA35D17678FEC51907272B1BAE2 ...WS.. CN=*.exchangeserverpro.net, OU=IT, O=LockLAN Systems Pty Ltd, L...
A49E18338DB7B07E75D46DBF843D919A014F9A63 ....SF. CN=Federation
436C266B30409B25C13A7EC17CBD4E9F5D8DAD79 ....S.. CN=Federation
Next, capture the certificate as a variable.
[PS] C:\>$cert = Get-ExchangeCertificate -Thumbprint DE67EC3C8D679AA35D17678FEC51907272B1BAE2
Now, declare a new variable for the certificate issuer and subject values.
[PS] C:\>$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"
Now we can set the receive connector’s TlsCertificateName property without having to type out a long string containing the issuer and subject values.
[PS] C:\>Set-ReceiveConnector "EX2016SRV1\Client Frontend EX2016SRV1" -TlsCertificateName $tlscertificatename
Repeat that for every server and connector that will be handling the authenticated SMTP connections, i.e. if you’re using a load balanced SMTP namespace.
Your SMTP clients should now be able to securely authenticate without any warnings or errors appearing.
If you’re interested in how Exchange handles selection of a certificate when multiple certificates are bound to the SMTP protocol, here are some articles that explain it:
Hi, can someone help with syntax clarification?
$tlscertificatename = “$($cert.Issuer)
$($cert.Subject)”Should now be…
$tlscertificatename = “$(CertInfogoeshere?)
$(Subjectgoeshere?)”TIA
Or
$tlscertificatename = “$($cert.Issuernamegoeshere?)
$($cert.SubjectNameGoesHere?)”Hey PAul,
I see this is an old post but I am having a similar issue. I have a valid hybrid connection to O365. When trying to move the O365 connector to on prem from a Kemp to a NetScaler I get the following. All the certs, connectors and IPs are exactly the same. Simply changing the internal VIP to point to the NetScaler. Any ideas?
450 4.4.317 Cannot connect to remote server [Message=SubjectMismatch]
Hi Paul,
I tried this and updated my both receive connectors..
But the error from the event log still flowing…
Any other idea on what else i can look into.
Hi Paul,
I tried but run into problems.
Please could you help me where is problem?
Thanks
Mojmir
[PS] C:\>Enable-ExchangeCertificate -Thumbprint 52B4EA653352E65B059E2A7A703E415AF12F0D74 -Services SMTP
WARNING: This certificate will not be used for external TLS connections with an FQDN of ‘mail.sonavox.cz’ because the
CA-signed certificate with thumbprint ‘61346FAF8BAD35A49D743668C82701D1205B826B’ takes precedence. The following
receive/send connectors match that FQDN: Client Frontend MAILSERVER, Default Frontend MAILSERVER.
Hi Paul
Thanks for sharing this fix. It’s still useful 4 years later! It resolved the exact issue as described along with an issue we saw for users receiving password prompts when outside the corporate network.
Thanks!
Pingback: Exchange and TLS problems – Kenneth Dalbjerg
Pingback: FET ports « rakhesh.com
Thank you.
As you stated a lot of sites saying what the problem was, but thankfully you took the time to provide the solution.
Very helpful. Many thanks
Hi Paul,
This helped resolving the issue, keep rocking…
Thanks,
Kannan
Hi Paul,
I’ve been on a deep-dive trying to troubleshoot my Exchange 2013 server for the last couple days. It takes a long time (hours, half a day in some cases) for a 20MB email to come inbound after a number of retries by Mimecast.
I also have the schannel issue, and as one person above mentioned, I thought I had to live with it too. Well I applied your fix and the schannel errors stopped.
We’ll see if it has any effect on the slow large-email delivery but I’m willing to try almost anything at this point!
Thank you.
I am having the dreaded “A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 46” error on an Exchange 2016 server in a DAG. I followed the directions above and now have a TlsCertificateName in the receive connector properties. I have also done a packet capture for the time frame the error occurs but an not sure what to look for. Any suggestions would be greatly appreciated. Thanks so much for all your articles and assistance.
Hi Paul,
thanks, solved my problem!
Hi Paul – Is there any way of undoing the -TlsCertificateName change/reverting back to null?
Thanks
Set-ReceiveConnector “EX2016SRV1\Client Frontend EX2016SRV1” -TlsCertificateName $null
Hi Paul,
From start till now I have been following all of your guide here. But for today I just have to leave a comment because this guide was superb. Been search for 2days now for the problem connecting smtp client. Looking forward to more guide and tutorial. You rock! Thank you very much! Good day!
The Real Person!
The Real Person!
Glad you found it useful Chi.
hi paul we have configured tls certificate for our receive connector.
however due to no internet connectivity on my exchange server we are getting revocation check failure and seems due to same reason our application could not able to send mails over 587 tls.
exchange 2016
windows 2016
mail does not go without confirming certificate validation.
how can we resolve revocationcheckfailure without internet connection.
The Real Person!
The Real Person!
I don’t know. Probably best to allow certificate revocation checks instead. That’s pretty important.
Thanks so much for this article. I thought SCHANNEL “A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 46” polluting the event log was just something I had to live with.
Is there anyway to revert these changes outside of powershell? Exchange management shell no longer connecting, nor can I log into the Exchange Administrative Center.
Is there anyway to revert these changes outside of powershell? Exchange management shell no longer connecting, nor can I log into the Exchange Administrative Center.
PS:
Failed to connect to an Exchange server int he current site.
Enter the server FQDN where you want to connect:
Management console loads login prompt, but after entering credentials:
[HttpException (0x80004005): The call to Microsoft Exchange Active Directory Topology service on server ‘TopologyClientTcpEndpoint (localhost)’ failed. Error details Either the target name is incorrect or the server has rejected the client credentials.]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +525
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +124
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +700
nmap -script ssl-cert is showing same certificates as it was before changes were made.
The Real Person!
The Real Person!
If all you changed was the TLS certificate name on a receive connector then that should have had no impact on PS or the EAC. If you think the HTTPS certificate binding is the problem then you can look at that through IIS management console as well.
Thank you, this was very helpful.
We have an edge transport configuration, for our Exchange hybrid deployment. The edge servers are used only for hybrid mail. They are subscribed via edgesync to our Exchange site.
I found that the tlscertificatename setting, when set to “cn=name,o=org,c=location
cn=name,o=org,c=location” would cause my send connector to stop synchronising over to the Edge server. If i set the TLScertificatename $null it would synchronise correctly.I ended up having to set tlscertificatename to only “
edge.company.com” only and left the rest off. O365 is happy, and my edge subscription is synchronising correctly.Hope this helps someone in the future, or perhaps some insight into other issues for someone else.
Ok apparently and cause italics and strikethrough. here’s what my comment was supposed to say. The two fields have “” added to prevent the formatting.
I found that the tlscertificatename setting, when set to “cn=name,o=org,c=locationcn=name,o=org,c=location” would cause my send connector to stop synchronising over to the Edge server. If i set the TLScertificatename $null it would synchronise correctly.
I ended up having to set tlscertificatename to only “edge.company.com” only and left the rest off. O365 is happy, and my edge subscription is synchronising correctly.
Hope this helps someone in the future, or perhaps some insight into other issues for someone else.
Hi Paul!
I configured my Client Frontend Receive Connector to use my external certificate which is associated to IMAP.
When I configure Outlook to use IMAP for Outbound, using SMTP Port 587 for (With TLS or without TLS) it works correctly.
But when I configure Mobile Devices (Android/iOS) to use IMAP for Outbound, using SMTP Port 587, it only works with TLS. It is not possible to use without TLS.
What is wrong?
Hi Paul, I gave this a try and I am still seeing the default self signed cert when I perform a CheckTLS test:
[000.212] We can use this server
[000.212]TLS is an option on this server
[000.212]–>STARTTLS
[000.282]<– 220 2.0.0 SMTP server ready
[000.282]STARTTLS command works on this server
[000.467]SSLVersion in use: TLSv1.2
[000.467]Cipher in use: ECDHE-RSA-AES128-SHA256
[000.467]Connection converted to SSL
[000.470]Certificate 1 of 1 in chain:
serialNumber= 75:65:e9:1a:f9:29:de:b7:4a:21:90:9e:41:54:b5:1f
subject= /CN=EX2013-MAIL1
issuer= /CN=EX2013-MAIL1
[000.471]Cert VALIDATION ERROR(S): unable to get local issuer certificate, unable to verify the first certificate
I have issued the Enable command with my Cert from GODADDY CA assigned it to SMTP confirmed it stated to overwrite, performed the change on the receive connectors, and alass nothing.
Any help would be appreciated, as I can't seem to find a solution. Thanks
The Real Person!
The Real Person!
Which receive connector did you configure?
Hi Paul, We have a scenario where we have two certificates installed on Exchange (one that is expiring and one that has just been issued) and both those certs have the same Issuer and Subject name. Will this process ensure a specific certificate is definitely used (via the Thumbprint) or does Exchange just look at the Issuer / Subject name to match things up.
The Real Person!
The Real Person!
Good question, and I’m not 100% sure, but last time I updated my Exchange certs I didn’t need to reset the TLS config on the receive connector, it just kept working, so I suspect that if the issuer and subject are the same it will just keep working.
I did exactly what is on your blog, but in my case it did not work. It continues to present a prompt with my certificate, which in the case is a wildcard. My certificate is a * .domain.com and the FQDN name of the Connector is mail.domain.com.
The Real Person!
The Real Person!
What does the prompt say?
I did exactly what is on your blog, but in my case it did not work. It continues to present a prompt with my certificate, which in the case is a wildcard. My certificate is a * .domain.com and the FQDN name of the Connector is mail.domain.com.
Hi Paul,
I am setting up a hybrid office 365 with a third party email filtration (proofpoint). MX points to proofpoint and office365 is authorized as a receiving and sending server.
Mail flow to office365 Mailboxes works fine, but mail flow to the on-premises mailbox is deferred with below error.
Reason: [{LED=450 4.4.317 Cannot connect to remote server};{MSG=451 5.7.3 STARTTLS is required to send mail};{FQDN=mail.mydomain.com};{IP=xxx.xxx.xxx.xxx};{LRT=5/2/2017 12:55:45 PM}]. OutboundProxyTargetIP: xxx.xxx.xxx.xxx. OutboundProxyTargetHostName: mail.mydomain.com
Later on, emails may get released from office365 queue to the on premise MB when office365 forwards the email to proofpoint MX records!
I do have a valid SSL certificate.
is this related to my receive connector on my clustered EX2013 DAG? my cluster is as the following:
2 x on-prem CAS server
2 x on-prem MB server
1 x remote CAS server (remote disaster center)
1 x remote MB server (remote disaster center)
how can solve this issue?
The Real Person!
The Real Person!
Does mail.mydomain.com resolve in DNS to your on-premises Exchange server(s)?
Yes it does
The Real Person!
The Real Person!
You might have a connector conflict. Check your receive connectors on the servers that should be receiving the O365 mail flow. Turn on protocol logging for each of them, and then review the logs to see which connector is trying to handle the incoming connection from EXO. Also check that any firewalls are not trying to do SMTP inspection.
Hi Paul, do any services need to be restarted after doing this? I implemented on Exchange 2016 for the “default frontend” connector for both servers and it is still happening.
The Real Person!
The Real Person!
I don’t think I needed to restart anything. If you suspect a service restart might be necessary you can try restarting the transport services on your server.
Thanks, it resolve my issue
Once again Paul saves my bacon. Thanks!
Hi Paul,
Having issues with 2010 sp3 as well, going by the article you linked – if you change the FQDN to match the name of the external cert, it should then use that cert for SMTP rather than the self signed?
If not that simple, is there another way of achieving the same outcome?
Thanks
Is there any solution to get this working on Exchange 2010 SP3 ?
I get the same error as Joshua.
receive the following result:
“A positional parameter cannot be found that accepts this agrument ‘-TlsCertificateName’.
Looking up Set-ReceiveConnector with Get-Help does not show a parameter available called TlsCertificateName.
Please let me know the best way to achieve this ?
My question is why doesn’t the normal certificate enablement process just do this by default? IMHO, it’s a bug that Exchange 2013/2016 don’t use the certificate explicitly enabled for assigned services and continue to leave default self-signed certificates assigned and in use by SMTP and IIS (back-end port 444 binding). Enabling a certificate for a named service (SMTP, IIS, POP, IMAP) should by default make it the active certificate in use.
I appreciate that MS may be trying to ensure STARTTLS availability and back-end SSL use out of the box for connections where certificate trust are less of an issue. And it’s great that TLS certificate assignment is possible to specific connectors for unusual corner cases where unique names/certificates are assigned on a per connector basis.
But it’s bad and nonsensical to install default certificates and leave them active after PKI certs have been installed and enabled for the assignable high level services.
The Real Person!
The Real Person!
My understanding is that SMTP is a little different because it needs to cater for both server to server communications (servers address each other by their real names, and the self-signed certs are used for TLS) and client to server communications, as well as other scenarios like hybrid mail flow, partner connections, and so on, that all might use different certificates and namespaces.
This does not appear to work on Exchange 2010. When attempting to run:
Set-ReceiveConnector “ConnectorName” -TlsCertificateName $tlscertificatename
I receive the following result:
“A positional parameter cannot be found that accepts this agrument ‘-TlsCertificateName’.
Looking up Set-ReceiveConnector with Get-Help does not show a parameter available called TlsCertificateName.
Is there another way to associate a certificate with a receive connector?
The Real Person!
The Real Person!
Doesn’t look like Exchange 2010 can be configured using the same technique. The selection process here might help you though:
https://technet.microsoft.com/en-us/library/bb430748(v=exchg.141).aspx
Dear Paul,
once again you rocked the Exchange – Thank you very much for this guide (and all the others) – Much appreciated.
Cheers mate,
Hans
Hi Paul,
With new version of your page there is bug in command ‘[PS] C:>$tlscertificatename = “<i>$($cert.Issuer)<s>$($cert.Subject)” ‘. As you know, it should be ‘[PS] C:>$tlscertificatename = “$($cert.Issuer)
$($cert.Subject)” ‘.Regards,
Szymon
Lol, comment got really messed up. Anyway, you know what to do.
Regards,
Szymon
for what it is that “? I got it in my exchange and it looks like this: CN=GeoTrust,
Thanks
Thank you.I was also struggling to solve this issue .This trick helped me to stop certificate prompt while using tls encryption
Thank you. I have been struggling to get STARTLS working with Exchange 2013 and Mimecast. I was puzzeled on why Exchange kept presenting a self signed cert that was not even assigned to SMTP service instead of the wildcard cert.
This did the trick!
Once again your site has solved a problem that was driving me crazy after deploying a Ex2016 server to accept inbound email.
Thanks very much Paul.
Hi Paul,
Would i need to make this change for all receive connectors on Exchange 2013 server?
Identity Bindings Enabled
——– ——– ——-
CEGEXCH2013Default CEGEXCH2013 {0.0.0.0:2525, [::]:2525} True
CEGEXCH2013Client Proxy CEGEXCH2013 {[::]:465, 0.0.0.0:465} True
CEGEXCH2013Default Frontend CEGEXCH… {[::]:25, 0.0.0.0:25} True
CEGEXCH2013Outbound Proxy Frontend … {[::]:717, 0.0.0.0:717} True
CEGEXCH2013Client Frontend CEGEXCH2013 {[::]:587, 0.0.0.0:587} True
CEGEXCH2013Copiers {0.0.0.0:26, 0.0.0.0:25} True
CEGEXCH2013UPS {0.0.0.0:25} True
Sorted – selected the Default Frontend connector and logs have stopped!
Great help thanks Paul
Excellent post.
Helped me much after looong nights ans days scrumbling with this headache !
Thank you so much!
It seems so shortsighted that Microsoft would create a GUI and cmdlets to set a certificate, but then overlook a component that is so critical to have the cert applied.
This fixed my issue, and it was only after many hours of searching! I knew it was using the wrong cert I just didn’t understand WHY.
Thanks Paul. Great post !
Many thanks for sharing – used the information you provided to get certificate validation working between my on-premises Exch 2013 Server and O365 EOP. It’s now working both ways (relaying out, and receiving filtered mail in) via using my trusted wildcard certificate 🙂
Having looked everywhere on the web, I eventually stumbled across your post and it has worked a charm – thanks very much! 🙂
Hi bobby ,
could you please explain how did you achieve this?
Paul.
this also fixed a STARTTLS issue with a front end connector at one of our clients. A valid cert was in place for SMTP but STARTTLS would not initiate.
this procedure cured cracked it. Now responding to STARTTLS.
brilliant
Hi Kevin ,
could you please explain how did you achieve this in detail
Thanks for tracking this down. Looks like the MS documentation needs a little work.
Once the cert was configured I got a error “530 5.7.1 Client was not authenticated” even though both Outlook and Thunderbird are configured for SMTP user authentication. I can get a success by enabling Anonymous Users” permissions but won’t because it is a very bad idea. Following https://community.office365.com/en-us/f/148/t/176699 led me to explicitly add the mailbox user to the Send As list on the same user through ECP to fix it. I’m not sure why that was required but there you go. I also didn’t have to include the NETBIOS domain name with the user ID.