Exchange 2013 Edge Transport Server and SSL Certificates

When installing an Exchange 2013 Edge Transport server a self-signed certificate is created and configure for use with the SMTP Transport server. The self-signed certificate has the NetBIOS hostname as the Common Name and the FQDN in the Subject Alternate Names field.

You can view this self-signed certificate using the Certificate MMC snap-in:


Exchange servers in general use ‘opportunistic TLS’ (ever since Exchange 2007), so when a certificate is available it tries to use TLS using a certificate. Since the certificate is used only for encryption and not for server validation or authentication the self-signed certificate can be used.

To check this you first have to enable protocol logging on the Edge Transport server, this can be achieved on the Exchange 2013 Mailbox server (which pushes the configuration to the Edge Transport server) using the following command:

Get-SendConnector –Identity “EdgeSync – Amsterdam*” | Set-SendConnector –ProtocolLoggingLevel Verbose


As you can see in the screenshot above the Protocol logging is disabled by default. When this command has been executed restart the MSExchange Transport service on the Edge Transport server.

Protocol log files are stored on the Edge Transport server in the directory C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Edge\ProtocolLog\SmtpSend. When you send an email you’ll see something like this in the protocol log file:


Clearly visible is the certificate exchange between this Edge Transport server and the SMTP server. Please note the Certificate thumbprint, it is the same thumbprint as shown in the first figure in the blogpost.

On an Exchange 2013 Client Access server (the same is true for Exchange 2007 and Exchange 2010 BTW) you have to replace the self-signed certificate with a 3rd UC certificate. But how about the self-signed certificate on the Edge Transport server?

There’s no need to replace the self-signed certificate on the Edge Transport server since the opportunistic TLS mechanism still don’t use the validation and authenticating purposes, it’s still used for encryption purposes only. The only reason I can think of is to have to UC certificate with multiple names on it (i.e.,,, that can be used on all Exchange 2013 servers.

Note. I’m just talking about opportunistic TLS as used by normal SMTP communication between SMTP servers on the Internet (when they support this of course). Using TLS for Domain Security is different implementation. When implementing Domain Security you have to create a connector dedicated for another organization (and vice versa) and create a 3rd party SSL certificate for this dedicated connector. The other organization has to do the same for your organization. Besides this, Domain Security is implemented on the Exchange 2013 Mailbox server (or Exchange 2010 Hub Transport server) and NOT on the Edge Transport server. I’ll get back on this in a future blog post.

But if you really want to replace the self-signed certificate on the Exchange 2013 Edge Transport server (‘just because you can’) you can use the following steps to do so. To create a new Certificate Request use the following command on the Edge Transport server:

$ReqFile = New-ExchangeCertificate -GenerateRequest -SubjectName “c=NL, bv, ou=RND,” -DomainName -PrivateKeyExportable $true

Set-Content -Path C:\Temp\Request.reg -Value $ReqFile

Logon to the CA you’re normally using (I use Digicert for my SSL Certificates) and upload the Request File we just generated.


When the request is submitted and the domain is successfully validated you should receive the SSL certificate. Store this file on the C:\Temp directory on the Edge Transport server and enter the following command:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\temp\smtphost-exchangelabs-nl.cer -Encoding byte -ReadCount 0))

When you use the Get-ExchangeCertificate you’ll see the newly created SSL Certificate:


To enable this SSL Certificate for SMTP usage enter the following command:

Enable-ExchangeCertificate -Thumbprint 888F51388D257F86F0BC4FE90682A7FF998512B0 -Services SMTP


The warning is important! Since the Edge Synchronization is using the SSL Certificate as well you have to recreate the Edge Subscription!

As a side note: you can export the newly created SSL certificate to a PFX export file using the following commands:

$file = Export-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -BinaryEncoded:$true -Password (Get-Credential).password

Set-Content -Path “c:\temp\smtphost.pfx” -Value $file.FileData -Encoding Byte

When the protocol logging is enabled again (remember that the Edge Subscription was recreated and the previous change is lost) you can see the newly created certificate is used in TLS communications with other SMTP hosts.


But then again, opportunistic TLS uses the new 3rd party certificate, but it still is only used for encryption purposes and no validation or authentication purposes so it has little to no added value at all. If you want to secure your SMTP traffic you have to implement Domain Security (on the Exchange 2013 Mailbox server and not on the Edge Transport server).

6 thoughts on “Exchange 2013 Edge Transport Server and SSL Certificates”

  1. Just wanted to say thanks since I’ve been landing on several of your blog posts during my studies for Exchange / Office 365. I also would point out that as it relates to the self-signed certificate, the only official place I can find direction for whether to leave it alone is in the Exchange Deployment Assistant. Both for the internal Exchange servers and the Edge servers, the direction is to leave the self-signed certificate as the default SMTP cert, even though the 3rd party cert is assigned SMTP as well. The reason is to avoid having the same cert on the Edge and the internal Exchange server being used at both ends of a secure transaction which is prohibited and won’t work.

    For a long time, I’ve thought that I want to remove the self-signed certificate, but finally now that I have slowed down and read more thoroughly in my studies, I see that my best move is to leave the self-signed certs in place, and just renew them as needed which can be done with zero down time anyway. This makes it easiest/safest to have the same 3rd party cert on all my servers including the Edge and never hit a problem.


    1. Agreed, no need to remove the self-signed certificate. It is also used by the Edge synchronization, and if you use a 3rd party certificate for Edge sync you run into authentication issues as well for the same reason as you mention, thanks.


  2. Hi Jaap,

    For some reason, the self-signed certificate is visible externally on the edge servers, even though we imported a signed certificate and set it to default for the SMTP service.

    Any ideas? We’re seeing a big risk in deleting the self-signed certificate where things might break down.



    1. the imported certificate should be returned when connecting using the correct FQDN (that’s also in the certificate). If not the self signed certificate is used. This certificate is also used for internal SMTP-SMTP communication and encryption, and for Edge-Mailbox server authentication (if used of course)


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s