Home » Exchange Server » Configuring the TLS Certificate Name for Exchange Server Receive Connectors

Configuring the TLS Certificate Name for Exchange Server Receive Connectors

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.

Next, capture the certificate as a variable.

Now, declare a new variable for the certificate issuer and subject values.

Now we can set the receive connector’s TlsCertificateName property without having to type out a long string containing the issuer and subject values.

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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

14 comments

  1. Howell Strain says:

    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.

  2. Kevin Haydon says:

    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

  3. Bobby says:

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

  4. Mirek says:

    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.

  5. Tony says:

    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

  6. Collin says:

    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.

  7. The_Doctor46 says:

    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!

  8. sajith k j says:

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

  9. Szymon says:

    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

Leave a Reply

Your email address will not be published. Required fields are marked *