Edge Transport Server, EdgeSync, and Certificates

Problem

The use of Exchange Edge Transport Servers requires synchronising user and configuration data from internal Exchange Servers to the Edge Transport Servers. The synchronization utilizes secure LDAP (EdgeSync) to transmit the data securely and is based on an Edge Subscription.

When you create a new Edge Subscription on your internal Exchange Servers by importing the Edge Subscription XML file, establishing the EdgeSync-connection might fail.

You will find the following error in the application event log of the internal Exchange Server:

Log Name:      Application
Source:        MSExchange EdgeSync
Event ID:      1035
Task Category: Synchronization
Level:         Error
Keywords:      Classic
Description:
EdgeSync failed to synchronize because it only supports Cryptographic API certificates. The local Hub Transport server's default certificate with thumbprint XYZ isn't a CAPI certificate. To set a CAPI certificate as the default certificate, use the Enable-ExchangeCertificate cmdlet with the Services parameter using the value of SMTP.

Reason

The private key of the current Exchange Transport default certificate of the internal Exchange servers uses a CNG private key. EdgeSync requires a CAPI1-based private key.

• CNG = Cryptography Next Generation
• CAPI1 = Cryptographic API (already deprecated)

This problem occurs primarily when using an Enterprise Certificate Authority using certificate templates with individual template settings. 

How do you determine if the type of the default transport certificate is a CNG or CAPI1 certificate?

• Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session.
• Query the Transport Service to identify the default certificate thumbprint.

Get-TransportService | ft Name,InternalTransportCertificateThumbprint

• Open an administrative command prompt.
• Export the certificate information from the certificate store to a text file.

certutil -v -store my > cert.txt

• Open the text file using an editor tool of your choice
• Search for the certificate thumbprint identified in Step 2
  This thumbprint is the SHA1 certificate hash
• Scroll down to the provider section to find the following two attributes
  • ProviderType
  • KeySpec

If both attributes have a value of 0, the certificate is a CNG certificate.

The section might look like this:

Unique container name: XYZ    
Provider = Microsoft Software Key Storage Provider    
ProviderType = 0  
Flags = 20 (32)    
CRYPT_MACHINE_KEYSET -- 20 (32)    
KeySpec = 0 -- XCN_AT_NONE

Solution

Use OpenSSL to convert the CNG certificate to a CAPI1 certificate.

Using OpenSSL requires the download of the Windows release of OpenSSL. I recommend not installing the software on the Exchange Server but on a separate Windows server or your administrative desktop system. Additionally, you need the certificate with its private key as a PFX file.

Use the following steps to convert the CNG certificate to a CAPI1 certificate.

• Download and install OpenSSL
• Open the OpenSSL Command Prompt
• Navigate to the folder containing the PFX-file
• Convert the PFX file to a PEM-file
  The tool will query to enter the PFX password

openssl pkcs12 -in CERT.pfx -out cert.pem -nodes

• Convert the PEM file to a new PFX-file
  The tool will query you to set a PFX password

openssl pkcs12 -export -in cert.pem -out NEWCERT.pfx

The new PFX file is now a CAPI1 certificate. The new certificate has the same thumbprint. Now you must replace the current certificate used by Exchange Server with the new certificate. 

Replacing the certificate requires downtime of each Exchange Server requiring the certificate replacement. This is due to the requirement to remove the CNG certificate first, following the import of the CAPI1 certificate. Afterwards, you need to enable the required Exchange services.

• Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session.
• Query local Exchange Server certificates and identify the thumbprint of the default Exchange Server self-signed certificate 
  The certificate common name (CN) equals the server name

Get-ExchangeCertificate -Server SERVERNAME

• Change the Exchange Transport default certificate to the self-signed certificate before deleting the CNG certificate

# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint THUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport

• Remove the CNG certificate
  • Use the certificate store MMC, Exchange Management Shell, or Exchange Admin Center.
• Import the CAPI1 certificate.
  • Use the certificate store MMC, Exchange Management Shell, or Exchange Admin Center.
• Enable the imported certificate and replace the default transport certificate.

# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint NEWCERTTHUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport

• Repeat the certificate replace for each Exchange Server in the same Active Directory site.

Now that you updated the local Exchange Servers, one more step needs to be checked on the Edge Transport Servers.

Edge Transport Servers are not domain-joined and therefore do not receive any GPO-based configuration. Each required configuration must be performed locally. To ensure that the default transport certificate of the internal Exchange servers can be used for cryptographic operations, we must ensure that the certificate chain of that certificate is present in the certificate store of Edge Transport servers.

Look at the converted CAPI1 certificate chain and import the Root-CA and Subordinate-CA certificates into the Edge Transport servers’ local certificate store. You must ensure that the certificates are placed in the appropriate stores:

• Root-CA certificate goes into Trusted Root Certification Authorities \ Certificates
• Subordinate-CA certificate goes into Intermediate Certification Authorities \ Certificates

Next, you create a new Edge Subscription on your Edge Transport server and create a new subscription for the Active Directory site on the internal Exchange Server. The internal Exchange Servers can now establish an EdgeSync connection and encrypt the data transferred to the Edge Transport servers.

Note

You import the certificate and the private key when you receive the TLS certificate as PFX/PKCS12 file. The import process itself defines the private key Crypto Provider. Using the following command line, you ensure the import process uses the legacy crypto provider.

certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx my MYCERT.pfx

Links

• Exchange Edge Transport Server Role
• Edge Subscriptions
• Cryptography API: Next Generation
• Cryptographic Service Providers
• OpenSSL for Windows

Enjoy Exchange Server and Edge Transport!

Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts. Follow us on Twitter @exusg, join on Meetup, or visit our website.