Friday, December 16, 2011

Wild Card Certificates and Hybrid Configuration Wizard

When running the Hybrid Configuration Wizard I noticed the wizard crashes when attempting to create a Send Connector if a wild card certificate is attached to the default web site in IIS. What the Hybrid Configuration Wizard does is look at the common name of the certificate associated with the IIS service (verify this by using Get-ExchangeCertificate) and attempts to associate the common name as the FQDN on the Send Connector for the purpose of SMTP encryption. In a wildcard certificate * is the common name of the certificate. * is not a valid FQDN for a send connector in Exchange as thee FQDN must be associated to a domain name, not a wild card name. As a result the wizard crashes when trying to set * as the FQDN on the send connector. The following error is generated...


Updating hybrid configuration failed with error 'Subtask Configure execution failed: Configure Mail Flow

Execution of the New-SendConnector cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.

Cannot process argument transformation on parameter 'Fqdn'. Cannot convert value "*" to type "Microsoft.Exchange.Data.Fqdn". Error: ""*" isn't a valid SMTP domain."
at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke()
at Microsoft.Exchange.Management.Hybrid.RemotePowershellSession.RunCommand(String cmdlet, Dictionary`2 parameters, Boolean ignoreNotFoundErrors)

Additional troubleshooting information is available in the Update-HybridConfiguration log file located at C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration\HybridConfiguration_12_16_2011_5_58_59_634596119396658235.log.

Exchange Management Shell command attempted:
Update-HybridConfiguration -OnPremisesCredentials 'System.Management.Automation.PSCredential' -TenantCredentials 'System.Management.Automation.PSCredential'

Elapsed Time: 00:07:13


I have a work around which will allow you to complete the Hybrid Configuration Wizard. What you need to do is use another certificate with a valid common name such as so the wizard is able to create its Send Connector. If you use a self signed certificate or a certificate issued by an internal certificate authority the wizard will fail. You must use a public certificate trusted from a public root certificate authority.

Does this mean I need to purchase another digital certificate, I already own a wild card certificate?

No, you can use a digital certificate from (provided by RapidSSL) which is free for 30 days. This certificate is not a SAN (subject alternative name) certificate which is trusted under multiple names. As a result you must issue the certificate to as the autodiscover service is required when running the Update-HybridConfiguration command. The autodiscover address must be pointed at the same address for the hybrid server in which your trying to configure on your firewall. When you finish creating your new certificate and associating it with the IIS service and SMTP service, re-run the Update-HybridConfiguration tool. Your send connector will be created with as the FQDN. Now you can re-assign your wild card certificate to the IIS service and SMTP service and update the FQDN on your send connector to a domain name of your choice in alignment with the wild card certificate such as

SSL Offloading...

If your running SSL offloading, i.e. your Exchange web services are all running on port 80 you still need to link a digital certificate to your IIS service to complete the wizard. Simply untick Require SSL on the various Exchange web services in IIS manager. The digital certificate you use needs to be valid for the FQDN on the SMTP service and must be linked to IIS and SMTP (Get-ExchangeCertificate).

Also if your using SSL offloading you do not have to worry about using on the certificate associated with IIS as the autodiscover requests will be hitting your Exchange server on port 80... another device such as Threat Management Gateway or an F5 BIG-IP will be decrypting the traffic and forwarding it to Exchange 2010.


  1. login to FOPE and check your Outbound Connectors under administration> company

    Where is says "The recipient certificate matches:" don't put your wildcard "*" put "" (or whatever you p reconfigured before)
    Send connector cannot have "*"
    if you have a wildcard recipient certificate matches: * = - it's logical TRUE

    Best regards,

  2. Hi Clint,

    As a heads up both of these issues are resolved in Rollup 1 for Service Pack 2, which will be released v.soon.

    Thanks you for posting about the new Hybrid Configuration Wizard.


  3. Hi Ben,

    When you say both these issues will be resolved in Rollup 1 for SP2 do you mean you will not need a digital certificate associated with IIS to complete the wizard for environments that use SSL offloading?

    What about MRSProxy... I found the hard way in a customers environment that MRSProxy to receive the requests on 443 not port 80, or it would not work...

    Please see:

    1. Typically a CAS server should always have a certificate assigned to it via the "Enable-ExchangeCertificate -Service IIS" cmdlet, even when you're performing SSL offloading. The fixes we've made in RU1 are to only warn (rather than error) if the certificate is not from a public certificate authority and to handle wildcard certificates.

      As for MRSProxy, we've updated the following article with steps for enabling SSL offloading:


  4. Ben,

    I'm keen to know what v.soon actually means. I have been in contact with Microsoft via the O365 service request portal and they cannot provide an ETA for this.


    1. Jonathan, Pls refer to my reply on the ehlo blog:


  5. We have the same issue in our environment, using SSL offloading.

  6. hello guys, thanks for the solution, i had the exact same problem, so thanks for posting!

  7. Hi Clint,

    Just to inform you and your followers. About 16 hours ago Microsoft released Update Rollup 1 for Exchange 2010 SP2.

    In this UR the problem should be fixed. I'm testing this at the moment and will write my findings on my blog later.


  8. As Cor said, this problem is now fixed for anyone reading this post.

  9. Problem still exists in Exchange 2013 CU3........

  10. A very nice Focus on why we need ssl point for our website. Now a days SSL certificate is as must as like SEO for protect our website online.