Exchange Server

Configuring the TLS Certificate Name for Exchange Server Receive Connectors

Avatar photo
Post author:Written By 66 Comments

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.

exchange-tls-certificate-name-02

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:

Tags: , , , , ,

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Ben Prickett 7 Feb 2022 Reply

    Hi, can someone help with syntax clarification?

    $tlscertificatename = “$($cert.Issuer)$($cert.Subject)”

    Should now be…

    $tlscertificatename = “$(CertInfogoeshere?)$(Subjectgoeshere?)”

    TIA

    1. Ben Prickett 7 Feb 2022 Reply

      Or
      $tlscertificatename = “$($cert.Issuernamegoeshere?)$($cert.SubjectNameGoesHere?)”

  2. Al C 17 Jan 2022 Reply

    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]

  3. jaszinho 28 May 2020 Reply

    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.

  4. Mojmir Sedlar 25 May 2020 Reply

    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.

  5. Ash 15 Apr 2020 Reply

    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!

  8. Dave Chapman 7 Dec 2018 Reply

    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

  9. Kannan B 3 Dec 2018 Reply

    Hi Paul,

    This helped resolving the issue, keep rocking…

    Thanks,
    Kannan

  10. Jason A. 3 Nov 2018 Reply

    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.

  11. David 21 Sep 2018 Reply

    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.

  12. Jens Westermann 7 Aug 2018 Reply

    Hi Paul,

    thanks, solved my problem!

  13. TF 27 Jul 2018 Reply

    Hi Paul – Is there any way of undoing the -TlsCertificateName change/reverting back to null?
    Thanks

    1. Yianni 15 Aug 2018 Reply

      Set-ReceiveConnector “EX2016SRV1\Client Frontend EX2016SRV1” -TlsCertificateName $null

  14. Chi Ochia 10 Apr 2018 Reply

    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!

  15. PNS 26 Mar 2018 Reply

    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.

  16. MarcK4096 8 Feb 2018 Reply

    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.

  17. Ted 19 Dec 2017 Reply

    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.

    1. Ted 19 Dec 2017 Reply

      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

      1. Ted 19 Dec 2017 Reply

        nmap -script ssl-cert is showing same certificates as it was before changes were made.

  18. Dirk 12 Oct 2017 Reply

    Thank you, this was very helpful.

  19. Will 11 Sep 2017 Reply

    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=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.

    1. Will 11 Sep 2017 Reply

      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.

  20. Felipe Cardoso 4 Sep 2017 Reply

    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?

  21. Brandon 25 Aug 2017 Reply

    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

  22. Mark Needham 14 Jun 2017 Reply

    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.

  23. Eder Silva 11 May 2017 Reply

    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.

  24. Eder Silva 11 May 2017 Reply

    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.

  25. Raed 4 May 2017 Reply

    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?

      1. Raed 6 May 2017 Reply

        Yes it does

  26. LouHarle 25 Apr 2017 Reply

    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.

  27. Nadeem Afzal 4 Apr 2017 Reply

    Thanks, it resolve my issue

  28. John S 1 Mar 2017 Reply

    Once again Paul saves my bacon. Thanks!

  29. TK 23 Feb 2017 Reply

    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

  30. Dazzler 20 Feb 2017 Reply

    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 ?

  31. Shawn Barnhart 19 Feb 2017 Reply

    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.

    1. Avatar photo
      Paul Cunningham

      The Real Person!

      Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.

             20 Feb 2017 Reply

      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.

  32. Joshua 11 Feb 2017 Reply

    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?

  33. Hans Heiser 1 Feb 2017 Reply

    Dear Paul,

    once again you rocked the Exchange – Thank you very much for this guide (and all the others) – Much appreciated.

    Cheers mate,
    Hans

  34. Szymon 16 Jan 2017 Reply

    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

    1. Szymon 16 Jan 2017 Reply

      Lol, comment got really messed up. Anyway, you know what to do.

      Regards,
      Szymon

  35. Luciano 24 Nov 2016 Reply

    for what it is that “? I got it in my exchange and it looks like this: CN=GeoTrust,

    Thanks

  36. sajith k j 19 Oct 2016 Reply

    Thank you.I was also struggling to solve this issue .This trick helped me to stop certificate prompt while using tls encryption

  37. The_Doctor46 13 Sep 2016 Reply

    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!

  38. Collin 17 Aug 2016 Reply

    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.

  39. Tony 4 Aug 2016 Reply

    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

    1. Tony 4 Aug 2016 Reply

      Sorted – selected the Default Frontend connector and logs have stopped!

      Great help thanks Paul

  40. Thomas 28 Jul 2016 Reply

    Excellent post.
    Helped me much after looong nights ans days scrumbling with this headache !

    Thank you so much!

  41. Mirek 20 Jul 2016 Reply

    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.

  42. JMO 10 Jun 2016 Reply

    Thanks Paul. Great post !

  43. Bobby 2 Jun 2016 Reply

    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! 🙂

    1. hazem 14 Mar 2017 Reply

      Hi bobby ,

      could you please explain how did you achieve this?

  44. Kevin Haydon 18 May 2016 Reply

    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

    1. hazem 14 Mar 2017 Reply

      Hi Kevin ,

      could you please explain how did you achieve this in detail

  45. Howell Strain 23 Apr 2016 Reply

    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.

Leave a Reply