[Today’s post comes to us courtesy of Shawn Sullivan and Justin Crosby]

** This post has been re-written on 8/25/2011 to cover a wider range of scenarios that have been generating an increasing amount of traffic recently.

The EBS 2008 Messaging Server is installed with two Exchange certificates; both are used for securing communication with the Security server. Specifically, one certificate is used by the Hub Transport role to secure EdgeSync communication with the Edge Transport Role and the other is for securing web communication between Forefront TMG and the Exchange virtual directories (this same certificate is also used for any application that uses port 443, such as OWA, Outlook Anywhere, TSGateway, and Remote Web Workplace).

Certificate Expiration Issues

The certificate used for Web traffic expires two years after its creation date. When it does, you will not be able to access resources such as OWA, ActiveSync, and RWW from the internet.

The certificate used for EdgeSync is valid for only one year from its creation date and you will start receiving warnings in Event Viewer once it expires:

Application
MSExchangeTransport
Error
12014
Microsoft Exchange couldn't find a certificate that contains the domain name Domain_Name in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Server with a FQDN parameter of FQDN. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Application
MSExchangeTransport
Warning
12015
An internal transport certificate expired.

NOTE: The certificate simply expiring will not cause EdgeSync or SMTP mail flow to stop working. You will just receive the above events and STARTTLS will be unavailable.

Recreating the Certificate

The following method should be used when either certificate has expired or has been accidentally deleted. This will fix both loss of web access and loss of mail flow between the Security and Messaging servers. Essentially we are replacing both certificates with single new one that will be valid for another 2 years. It will be issued by the trusted internal Certificate Authority while maintaining both original names to preserve certificate trust between the two servers.

Create the new certificate

  1. On the Messaging Server, launch Exchange PowerShell as admin.
  2. Run the following command to create a temporary directory for this process:
    md c:\EBSBlog
  3. Run the following commands to collect the $ComputerName, $FQDN, $Date, and $FriendlyName values you will need:
    $ComputerName = gc env:computername
    $DnsDomain = gc env:userdnsdomain
    $FQDN = $ComputerName + “.” + $DnsDomain
    $Date = Get-Date –Format d
    $FriendlyName = $Date + “ EBSBlogCert”
  4. Run the following command to generate the new certificate request:
    New-ExchangeCertificate –GenerateRequest –Path c:\EBSBlog\NewEBSCert.req –DomainName $ComputerName, $FQDN –FriendlyName $FriendlyName
  5. Run the following command to submit the request:
    CertReq –attrib “CertificateTemplate:WebServer” c:\EBSBlog\NewEBSCert.req
  6. When prompted, select your internal Certificate Authority and save the resulting certificate with the name NewEBSCert.cer back to the c:\EBSBlog folder.
  7. Run the following commands to import the certificate into Exchange and assign the necessary services:
    Import-ExchangeCertificate c:\EBSBlog\NewEBSCert.cer
    Get-ExchangeCertificate | Where {$_.FriendlyName –match $FriendlyName} | Enable-ExchangeCertificate –Services IIS,SMTP,POP,IMAP
  8. Select Y to overwrite the existing default SMTP certificate.

If the original transport certificate had been deleted previously, it is expected that you will receive the following informational/warning message:

New-ExchangeCertificate : The internal transport certificate for the local server was corrupted or missing in Active Directory. The problem has been fixed. If you have existing Edge Subscriptions, you must subscribe all Edge Transport servers again by using the New-EdgeSubscription cmdlet in the Exchange Management Shell.

Whether or not you receive this message, follow the steps below to recreate the Edge Subscription between the Hub role on Messaging and the Edge role on Security.

Recreate the Edge Subscription

From Security Server:

  1. Open Exchange PowerShell as administrator and run the following commands:
    md c:\EBSBlog
    New-EdgeSubscription –FileName c:\EBSBlog\new.xml
  2. Choose Yes to confirm.

    From Messaging Server:
  3. Copy the xml file from the Security server to the c:\EBSBlog folder on the Messaging server and run the following command:
    New-EdgeSubscription –FileName c:\EBSBlog\new.xml –Site Default-First-Site-Name
  4. Wait between 5 and 15 minutes, then test EdgeSync by running the following command to ensure that it’s working properly:
    Test-EdgeSynchronization

    clip_image001[1]

Once all entries say Synchronized, mail flow should be restored. If you are still having issues, you may want to contact Microsoft Product Support Services for assistance.

More Information

Missing Certificate

We often find that customers discover the expiration on their web certificate before they realize that their EdgeSync certificate has expired, since only the web certificate expiration will cause major functionality loss. We also find that many times customers are unintentionally removing the old certificates improperly during the course of troubleshooting, which can then break both inbound and outbound mailflow as well. In this circumstance, you may receive errors such as the following:

Application
MSExchangeTransport
Warning
12023

Microsoft Exchange could not load the certificate with thumbprint of <thumbprint> from the personal store on the local computer. This certificate was configured for authentication with other Exchange servers. Mailflow to other Exchange Servers could be affected by this error…

Application
MSExchangeTransport
Error
2018

Outbound direct trust authentication failed for certificate <SubjectName>. The target IP address of the Exchange server that Microsoft Exchange tried to authenticate to is <IPAddress>. Make sure EdgeSync is running properly.

Application
MSExchange EdgeSync
Error
1032

No credential was found for <Edge Server FQDN> …

451 4.4.0 Primary target IP address responded with: “454 4.7.0 Temporary authentication failure.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts