There is a lot of guidance out there that indicates that it isn’t possible to use wildcard certificates with Office Web Apps 2013. Much of this stems from one of the certificate requirements listed in this Technet document:
“The FQDN in the SAN field can’t begin with an asterisk (*).”
On first blush, this would in fact rule out wildcard certificated since their SAN (Subject Alt Name) or friendly name is the FQDN of the wildcard (*.domain.com). Indeed, there is no way in the IIS manager to alter the name of the certificate . Issuing a PowerShell command the create a new Office Web Apps server farm with the wildcard name results in the certificate being invisible to the command, and you receive the following error:
However, in my experience, wildcard certificates work just fine with Office web apps. There is just a trick to getting them to work.
The problem isn’t the wildcard certificate per se, it’s the fact that the friendly name can’t contain a wildcard. All that we really need to do is to change it. It’s not immediately obvious how that’s done, but it can be done through the MMC snap in.
If the certificate is already on the server, then great, but if not, you’ll need to import it. In this example, we’re importing a certificate that’s been exported from another server, a common enough scenario for wildcard certificates. However, the origin doesn’t matter.
The first thing you’ll need to do is to run MMC (Microsoft Management Console). To do this, from a command prompt, type MMC and hit enter. Then load the Certificates snap in, selecting the Local Computer store when prompted.
The location of the certificate is important. If it’s not in the right place, the new farm command won’t see it, and you’ll receive exactly the same error as above. The certificate needs to be imported into the Personal folder of Local Computer. Right click on the Certificates folder, hover over All Tasks, and select Import. Then, go through the prompts and select the certificate to import.
Once imported, we want to change its Friendly Name. We can do that by selecting the certificate, right clicking it, and selecting Properties.
From here, it’s a simple matter of changing the friendly name from the wildcard address, to something with significantly fewer asterisks, in our case xxxxxxwildcard
Once done, click OK, and close the MMC. Your certificate now has a friendly name that you can use to create your Office Web Apps farm.
New-OfficeWebAppsFarm -InternalUrl "https://xxx.xxxxxxxx.com" -ExternalUrl "https://xxx.xxxxxxxx.com" -CertificateName "xxxxxxWildcard" –EditingEnabled
Once created, you can continue to configure your Office Web Apps farm, and then bind SharePoint to it.
While I’m on the topic, and because it comes up frequently, once you have bound your SharePoint farm to the Office Web Apps server, it’s important to turn off view rendering for Excel files if your farm uses Excel Services. This is because the Office web apps don’t support data connections in Excel files, or PowerPivot models, and data interactivity won’t work. By issuing the following command:
New-SPWOPISuppressionSetting -extension xlsx -action view
we tell the SharePoint farm to use Excel Services (which supports data connections) when viewing xlsx files, not Office Web Apps.
Finally, if this is being added to an existing farm, you’ll want to run a full crawl to repopulate your search index with the new rendering mechanism for Office documents.
14 Comments