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 Outlook.com 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 3^rd 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. webmail.contoso.com, autodiscover.contoso.com, legacy.contoso.com, smtphost.contoso.com) 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 3^rd 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, o=Jaapwesselius.nl bv, ou=RND, cn=smtphost.exchangelabs.nl” -DomainName smtphost.exchangelabs.nl -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 3^rd 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).