RSS Subscription 168 Posts and 2,769 Comments

Secure SMTP between Edge Transport and Hub Transport

There seems to be some confusion as to how TLS connectivity between a Hub Transport and Edge Transport works. A large reason for this is due to the Exchange 2007 Edge Transport Server not being a part of your Corporate Active Directory.  Because of this, people may think, that by default, Hub SMTP communication between a Hub Transport and Edge Transport is not encrypted and are asking, “How to secure SMTP communication between a Hub Transport and Edge Transport is encrypted.” Well the answer is, it already is…. Let me explain.

One of the steps in connecting your Edge Transport Server is to export an Edge Subscription XML file once all your Edge Transport prerequisites are done.  An explanation of these prerequisites is out of the scope of this article.  There are many things that occur during XML export process and import process.

To export an XML, you would run the following command:

New-EdgeSubscription -FileName “C:\Edge.XML”

As stated, there are many things that happen during the export.  Before running the above command, you want to ensure you have a certificate on your Edge Transport Server that is enabled for SMTP use.  To check this, you can run the following command:


You should see that your server has a self-signed certificate that lasts for one year and is enabled for SMTP.

When exporting our XML file, the private key is stored in the local computer store and the public key is written to the Edge Subscription file.  Because of this, when you submit the XML file to the Hub Transport for importing, the Hub Transport will store a copy of this public key in Active directory. The Hub Transport will then use Active Directory as a Trusted Storage mechanism to validate the Edge Transport’s certificate. Vice Versa, when your Hub Transport and Edge Transport are now connected with each other, the Hub Transport will send a copy of its’ public key for an Edge Server to store in ADAM. It is because of this, both servers are allowed to take advantage of TLS communications for the secure transport of SMTP.

You don’t have to use a self-signed certificate.  If you don’t want your certificate to expire in one year and have to mess with it, you can use your own PKI cert or even a certificate from a 3rd party vendor.

Now what happens when you are approaching your certificate expiration date.  Well, even if your certificate expires, mail will still flow.  This is because our Transport servers use something called Opportunistic TLS. If you look at the Authentication Tab of your Connector, only Transport Layer Security will be selected. This is called Opportunistic TLS which means that TLS will be accepted and is the preferred method for communication, but TLS will not be required.  So even if your certificate expires, all that means is that mail will still flow, but less secure since TLS will not be able to be used.

As you can see, Transport Layer Security is selected.  Opportunistic TLS means that any time a sending server attempts to issue a StartTLS, our Exchange server will accept TLS communications and encrypt the communications.  By default, an Exchange 2007 Send Connector will accept StartTLS from a Receive Connector due to the Send Connector using the defined parameter IgnoreSTARTTLS which is set to false by default which means the Send Connector will accept StartTLS and utilize TLS for encryption for SMTP.  In order to see the setting on your Exchange Servers, you can type the following command:

Get-SendConnector “SendConnectorName” | fl

If you look on your Hub Transport, you may think that you see a Send Connector there going to your Edge.  This won’t be the case. A configuration object in Active Directory has a Site Association for an Edge Subscription.  Because of this, mail flowing from a Hub Transport to an Edge Transport utilizes the hidden Intra-Organization Send Connectors.

You will however, see the connectors that live on the Edge Transport Server. In reality, these Send Connectors or the Edge Server were created on our Hub Transport and live in Active Directory.  These Send Connectors get pushed out to the Edge Server via Edgesync replication.  To force this replication, you can type the following command:


You should then see your Send Connectors on your Edge Transport Server.

Now you can launch the Exchange Management Shell and run the Get-SendConnector command above on the connector which points to our Hub Transport Servers; which is the connector I highlighted.  Run the following command:

Get-SendConnector “edgesync – inbound to default-first-site-name” | fl

As you can see, IgnoreSTARTTLS is set to false which means our Send Connector will allow Mutual TLS to take place if the Receive Connector advertises StartTLS; which it does by default.  So as long as your IgnoreSTARTTLS settings are False, Opportunistic TLS is enabled, and your certificate is valid, Secure SMTP using TLS will work between your Hub Transport and Edge Transport Servers.

Now what happens when our certificate expires?  Well, we can renew our certificate on our Server.  There are some good instructions here.  One difference you’ll want to do is instead of enabling the certificate for IIS, you’ll want to enable the certificate for SMTP.

Now don’t forget that earlier in this article, I talked about how the Edge Transport and Hub Transport trust each other’s certificates.  Because we have a new certificate, we’ll have to re-subscribe our Edge Servers to our Hub Transport Servers.  This way, our Hub Transport can receive our new certificate and store it in Active Directory for a Direct Trust.

If you ever introduce new Hub Transport servers, they’ll be able to send and receive mail securely due to the Intra-Org Send Connector and using Active Directory as a Trusted Storage Mechanism, but these new Hub Transport Servers will not be able to participate in Edgesync replication.  In order to allow for this, your Edge Transport Servers will need to be re-subscribed, especially if you want the Edge Transport to be able to send mail securely to this new Hub Transport.  That is because, as I stated before, part of the initial process of subscribing an Edge Transport is the Hub Transport placing its’ certificate into ADAM.

When you go to renew your Hub Transport certificates, a simple Start-EdgeSynhcronization will take the Hub Transport certificates and place them into ADAM so the Edge Transport Servers will trust your Hub Transport Servers.


3 Responses to “Secure SMTP between Edge Transport and Hub Transport”

  1. on 18 Aug 2009 at 3:22 amJanne

    I have a problem with edge subscription
    edge sync has worked for 3 weeks, then something happened.
    now when i start-edgesynchronization i get “no credentials found for (edgeservername)
    i have removed edge cert, reinstalled exchange egde, stil same problem
    im out of ideas

  2. on 10 Sep 2009 at 2:09 pmBarak

    See if this helps:

  3. on 18 Aug 2009 at 10:31 amElan Shudnow

    I would probably increase the Diagnostic Logging to get more verbose logging of what’s happening. You’ll probably have to re-create the edge subscription as that’s the process that takes care of the credentials.

Trackback this post | Feed on Comments to this post

Leave a Reply