SharePoint hosted apps have been both a blessing and a curse for me. The blessings have more to do with the concept of having a self-contained application that runs using client-side code only and can be centrally managed via an app catalog. The curse is the initial configuration of the environment to fully support SharePoint hosted (and provider-hosted) apps with SSL. I needed to configure wildcard certificates for SharePoint Hosted Apps in my development environment.
Mismatched Address for Wildcard Certificate
Now, everything may seem to be working fine with SPHosted apps if you follow the Microsoft guidance for setting up an on-premises environment for SharePoint apps, however my environment is a complete install so I went with Microsoft guidance on how to create an environment for apps for SharePoint. I also wanted to use SSL and the Workflow Manager and I wasn’t about to put down some cash for a 3rd party certificate. Although the use of a self-signed certificate seemed to work just fine for my main SharePoint url (servername.mydomain.net), I did come across some issues with a ‘Mismatched Address’ when I setup a local DNS with a forward lookup zone for routing my SharePoint apps app domain url (guid.appdomain.net) because my self signed wildcard certificate was self-issued by my own server.
I can deal with just ignoring the error in the browser and be on my way with a functional SharePoint hosted app, but I ran into issues with Workflow.
SharePoint 2013 Workflows don’t work
Don’t get me wrong, I tested the SharePoint 2013 functionality using SharePoint Designer 2013 and was able to publish a workflow and get it to work. The real issue came from the following simple scenario:
- Create a SharePoint Hosted app with a list instance
- Add a workflow and associate it to the list instance (Manual, item added or updated). My simple workflow just writes to the log and updates the title with the current date/time.
- Install the app and add a list item
What ended up happening is the workflow would start, but nothing would happen. I knew that workflow was working, and I knew that my SharePoint hosted app was working, but for some reason the workflow would not get past Started. What could be the problem?
Debugging the workflow issue
Although opening up the workflow properties showed the workflow and let me see when it was last run, hovering over the little blue ‘i’ for more information came up empty.
The ULS logs didn’t really give me any more useful information either: “Workflow instance someguid is in retry state but GetRetryMessage threw exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.”
So I was off to the Event Viewer to see what was amiss. I dug down into the Event View -> Applications and Service Logs -> Microsoft-Workflow section and then made sure to allow the viewing of ‘Show Analytic and Debug Logs’.
Then I had to enable the Debug Log to see what was going on.
I came across an interesting error “An exception was thrown from the HTTP request to ‘https://app-guid.domain.net/Site/AppName/_vti_bin/client.svc/web/lists/getbyid(guid’somehexnumber’)/Items(1)’: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.”
Boom! I disabled the debug logging and then realized from this error that my Workflow was trying to make a service call to the SharePoint hosted app but was failing to communicate because of an SSL issue. I’m thinking the mismatched address was causing this to occur and I couldn’t just click ‘Continue’ because it was happening asynchronously form the server.
Creating a self-signed wildcard certificate
I’m not an SSL expert by any means, but I happened to stumble upon an excellent post by Mike O’Brien about Creating a self-signed wildcard certificate. I followed this blog post to create a new root Certificate Authority as the issuer of my wildcard cert for my SharePoint app domain using the following 2 commands in an elevated Visual Studio Command Prompt:
makecert.exe -n "CN=SharePoint Development Root CA,O=MYDOMAIN,OU=Development,L=Washington,S=DC,C=US" -pe -ss Root -sr LocalMachine -sky exchange -m 120 -a sha1 -len 2048 -r
makecert.exe -n "CN=*.appdomain.net" -pe -ss My -sr LocalMachine -sky exchange -m 120 -in "SharePoint Development Root CA" -is Root -ir LocalMachine -a sha1 -eku 22.214.171.124.126.96.36.199.1
Workflows within a SharePoint Hosted App are functional again
Now I could select my *.appdomain.net SSL certificate as my default within IIS site bindings for my Web Application. I then could open up my browser to try my SharePoint Hosted app with workflow. When I checked the status I saw that my workflow instance had completed successfully!