The following steps outlines the steps involved in configuring your Exchange Server to use a Godaddy SSL UCC certificate.

Before you begin, make sure that you have purchased an Exchange Server  UCC certificate from Godaddy. A UCC certificate allows you to have multiple SAN’s (Subject Alternative Name) necessary for the proper operation of Exchange. For example, having a SAN named autodiscover will allow your smartphone users to connect to the Exchange server without having to manually configure setting.

Open Exchange ECP and navigate to servers –> certificates.


Click on the + sign to start the certificate wizard. Choose create a request for a certificate authority and then click next.

Give the certificate a friendly name and then click next. Skip the wildcard certificate section by clicking next.

Select the server where the certificate will be stored and click next.

Highlight the default domain and

Select the access type (OWA, Autodiscover, etc.) and click on the edit icon to edit the settings.

The Internet access domains will display by default <not specified>, change them to your FQDN or to the following these settings:


Outlook Web App (Internet)


Exchange Web Services

Exchange ActiveSync


Outlook Anywhere

When finished, click next.

The next screen will display the SAN names. Remove all of the SANs except the public FQDN SANS.


The sans that should be left are, and

In the next window, enter your organization’s information.


Finally, save the certificate to a shared network folder folder. name the request certrequest.txt if possible.


Next, locate and open your certificate request then highlight and copy its content.


Now sign back into your Godaddy account in order to process the request. Locate the new certificate and click on the launch button. You will get a large paste area where you need to paste the contents of the certrequest.txt file.


Right click in the paste box and select paste from the pop up menu. Agree to the terms and conditions and click next.

Make sure that all of your SAN FQDN’s are present and match those that we specified in the Exchange certificate wizard.


You will receive a confirmation e-mail that you must approve by clicking on the confirmation link. Look in the pending requests page for the download arrow to appear solid instead of ghosted. This indicates that the certificate request is ready to download. Click update list periodically if necessary, it may take a couple of minutes to appear solid after you approve the SSL e-mail.


If you are in a hurry or if you get stuck, call GoDaddy. I don’t usually opine about organizations but I do have to say that GoDaddy has excellent customer service, especially when it comes to SSL certificates.

When you download, select Exchange 2010 as the type from the drop down menu. Download the certificate to a network share that’s accessible by the Exchange server.

You will need to extract it since it’s compressed in a zip file.


You will notice two files: a certificate file and an intermediate certificate file.

Log back in to the Exchange server’s ECP and go to servers –> certificates. Look for the pending request and click on the complete link.


Use a UNC path to point to the certificate file (not the intermediate certificate) click OK to import it.


Now, we need to import the intermediate certificate. Open PowerShell and execute MMC to open the Microsoft management Console.

Click on file –> add/remove snap in  and select certificates from the available snap ins list the click on add. When prompted, select computer account from the certificates snap in. Select the Exchange server when prompted to select computer.

Once the snap in for certificates is showing expand  certificates –> intermediate certificate authorities –> certificates.

Right click and select all tasks –> import and import the intermediate certificate.


Finally, go back to the Exchange control panel (ECP) and navigate to servers –> certificates.

Highlight the default domain and click on the edit icon. Select the services that will use this certificate and then click save.


Now we need to configure the virtual directory internal and external URL’s. Open ECP and navigate to servers –> virtual directories. Select OWA and click on the edit icon.


Change the external URL to the URL that matches the certificate.


Do the same for ActiveSync, OAB, ECP and EWS.


If you are planning to use Outlook Anywhere (Outlook RCP over HTTPS), navigate to servers and click to edit the server settings. Click on outlook anywhere and change the internal and external FQDN to the correct FQDN.


When done, open a command prompt on the Exchange server and execute IISRESET in order to apply the changes.


If you want users to authenticate using domain\user, then we are finished. Outlook Anywhere and ActiveSync devices will prompt you for login credentials and you should use the domain\user syntax. If however, you want to simplify things for the end users, you can create a UPN suffix for your domain in order to make autocomplete less complicated.

Creating a UPN Suffix

Creating a UPN suffix allows users to authenticate using their e-mail address, making the autocomplete process a single step. To do this, let’s create a UPN suffix so that Outlook Anywhere users and Active Synch Users can authenticate using the syntax.

In the Domain Controller, open Active Directory Domains and Trusts.  Right click on Active Directory Domains and Trusts and select properties. In the UPN suffix field, enter your domain name and click add, then OK.


When you create a new user for the Exchange account, select the user’s UPN from the drop down list.


The final piece will be to make sure that your connecting services are using the FQDN of the CERT instead of the Exchange server’s local domain or its NetBIOS name.

If your services are not using the correct FQDN, you will get the error:

“The name of the security certificate is invalid or does not match the name of the site.”

You can use the Set-ClientAccessServer command to configure this setting.

  • Set-ClientAccessServer -Identity “mbx1” –AutodiscoverServiceInternalURI https://FQDN/autodiscover/autodiscover.xml

For more information about this, click here to view Daniel Kenyon-Smith’s post about certificate mismatch errors .

Leave a comment

Your email address will not be published. Required fields are marked *

error: Sorry, copy/paste is disabled
Skip to content