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 *.example.com is the common name of the certificate. *.example.com 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 *.example.com as the FQDN on the send connector. The following error is generated...

Update-HybridConfiguration
Failed

Error:
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 "*.example.com" to type "Microsoft.Exchange.Data.Fqdn". Error: ""*.example.com" 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




Workaround...

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 mail.example.com 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 http://www.freessl.com/ (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 autodiscover.yourdomain.com 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 autodiscover.yourdomain.com 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 mail.example.com.

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 autodiscover.yourdomain.com 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.

12 comments:

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

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

    Best regards,
    Dar2

    ReplyDelete
  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.

    Ben

    ReplyDelete
  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:

    http://clintboessen.blogspot.com/2011/12/hybrid-office-365-deployment-with.html

    ReplyDelete
    Replies
    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:

      http://social.technet.microsoft.com/wiki/contents/articles/1267.how-to-configure-ssl-offloading-in-exchange-2010.aspx#Configuring_SSL_Offloading_for_the_Mailbox_Replication_Proxy_Service_MRSProxy

      Ben

      Delete
  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.

    Thanks,
    JP

    ReplyDelete
    Replies
    1. Jonathan, Pls refer to my reply on the ehlo blog: http://blogs.technet.com/b/exchange/archive/2011/12/08/introducing-the-hybrid-configuration-wizard.aspx

      Ben

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

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

    ReplyDelete
  7. Hi Clint,

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

    http://www.microsoft.com/download/en/details.aspx?id=28809

    In this UR the problem should be fixed. I'm testing this at the moment and will write my findings on my blog http://www.reinhard-online.nl later.

    Cor

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

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

    ReplyDelete
  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.

    ReplyDelete