How to Configure DNS and SSL for SharePoint 2013 Apps

SharePoint 2013 App ModelOne of the greatest additions that was introduced in SharePoint 2013 is the app model. This allows for stand-alone apps that add additional functionality to SharePoint. They can be hosted in a SharePoint environment or hosted completely outside of SharePoint by the provider themselves.

Configuring SharePoint 2013 to use apps is actually fairly straightforward and easy. Microsoft has documented most of it in their Technet blog. However, two of the most common questions I’ve been asked are due to confusion around the DNS configuration and how to actually apply the SSL for apps.

Part of this confusion is centered on how Microsoft recommends configuring DNS and how most admins are used to applying SSL certificates. Yes, these two issues are related, so if you came here wondering how to apply your app domain’s SSL, then you may have already run into an issue like this with your SSL secured SharePoint site:

SSL secured SharePoint site

So, today I’m going to talk through the DNS and SSL configuration for SharePoint 2013 apps. (If your site isn’t using SSL, then you could skip that part I guess, but why not stay along for the ride anyways?)

Part 1: DNS Configuration

Step 1: You will need to acquire an app domain.

It is strongly recommended that this domain is separate from your site’s domain. For example:

Example Site = mytestsite.onfpweb.net

Example App domain = onfpwebapps.net (completely separate from onfpweb.net)

Step 2: Configure DNS for both the site and the app domain.

So first, let’s talk about what the URL of an app would be.

Whenever a new app is added into SharePoint, it will be given a unique name with the app prefix and an app ID. In my example, it would look something like app-7422a132061cd3.onfpwebapps.net. So each app will have a URL that will be a unique sub-domain of your chosen app domain. It would become a little monotonous to keep adding new ‘A’ records in DNS for each app that you add. This is why we’ll be configuring the wildcard CNAME record in step 2c below:

  • Note: If you want to test the app store locally on your server then you’ll need to configure DNS in your SharePoint environment’s domain’s DNS.
  • Note: If your users will be using public DNS to access the site, then the following DNS records would need to be created on your public DNS servers for your site and your app domain as well.

Below is an example of the DNS configuration in my test server’s DNS settings using internal IP’s. Obviously for public DNS, I would be using the external IP’s instead.

2a. If they are not already created, then create two new Forward Lookup Zones for your site and app domain:

Forward lookup zones for your site

2b. Create an ‘A’ record for your SharePoint site. (It is “mytestsite.onfpweb.net” in my example):

Create an ‘A’ record for your SharePoint site

2c. Create a wildcard CNAME record for your app domain that points to your site URL

Create a wildcard CNAME record for your app domain

points to my site’s Fully Qualified Domain Name

(In my example, the wildcard record for my app domain, “*.onfpwebapps.net” points to my site’s Fully Qualified Domain Name “mytestsite.onfpweb.net”.)

What the wildcard CNAME record is doing is directing any traffic that goes to somerandomurl.onfpwebapps.net (app domain) towards mytestsite.onfpweb.net (the SharePoint site’s FQDN):

wildcard CNAME record directs traffic

Part 2: Configuring SSL

Remember when we created the wildcard CNAME record for our app domain to use? This technically means that anyrandomurl.onfpwebapps.net will be pointing to the same IP address as my SharePoint site. So let’s talk about IIS bindings and how they relate to this situation:

IIS bindings

Every IIS site must have a unique binding. That means that some combination of the IP address, port and host name has to be unique on the server. This is to prevent any conflicts of multiple sites trying to serve the same requests.

Before IIS 8, in order to have multiple SSL’s, the most common thing to do was to use a different IP address for each SSL site. This is due to the fact that you couldn’t specify host names in the bindings for an SSL site. This leads back to the situation I’m in with my app domain configuration. My app domain is pointing to my site’s FQDN in DNS which means that it’s using the same IP address. So how will we work that out?

Step 1: Acquire a wildcard SSL for your app domain. 

(In this scenario, it is assumed you’re already using SSL for your SharePoint site itself.)

Since I’m doing this in a lab environment, I am just using a self-signed certificate. In a production environment, you will definitely want to purchase the wildcard certificate from a 3rd party certificate authority.

purchase the wildcard certificate

Step 2: Create a placeholder web application for your app domain

This step isn’t technically necessary since you can add the additional app domain binding to one of your other SharePoint sites in IIS, but I like to do it to separate my SSL bindings to different sites in IIS. This web application will have no site collections since it’s not actually hosting any app content (remember that SharePoint apps can be hosted off the SharePoint server itself). It’s basically just going to serve as a placeholder:

no site collections in the app domain

(Screenshot showing that there are no site collections in the app domain placeholder web application)

alternate access mappings

(Screenshot showing the alternate access mappings for this web application)

Step 3: Update IIS bindings to use the SSL’s

This is where the magic is going to happen. The reason we can use multiple SSL certificates with the same IP address in IIS 8 is because of the new Server Name Indication option (SNI for short). This allows us to specify host names for SSL secured sites. Here are the bindings for my two SharePoint web applications:

My app domain’s placeholder web application has one HTTPS binding that is using the wildcard certificate and no Server Name Indication (since SNI requires that you specify one host name and each app would be using a different host name).

app domain’s placeholder web application

My SharePoint site’s web application’s bindings also have one HTTPS binding that uses the site’s specific SSL certificate. This binding is using the SNI option to specify the host name:

SharePoint site’s web application’s bindings

I added a simple app part to the home page of my SharePoint site and confirmed that I am no longer receiving any SSL certificate warnings for my site or the embedded app.

Adding app to SharePoint site homepage

Hope that helped! Thanks for reading!



Fpweb.net Admin Support Services



2015-02-23T09:37:26+00:00 February 23rd, 2015|

14 Comments

  1. Kim March 3, 2015 at 11:21 am - Reply

    Are you using separate IP address, one for the main site and one for the app domain? We are able to get to get the Apps to work internally without getting a certificate error, but externally it is not working.

    Any suggestions?

  2. Eli June 4, 2015 at 3:01 pm - Reply

    Does your “Open with Explorer” option work? I set the SNI and I can’t map to sharepoint or use the explorer option within sharepoint…

    How did you get around this?

  3. Martin July 1, 2015 at 1:06 pm - Reply

    Any ideas how to bind the app domain wildcard certificate if you are using host named site collections as you can’t specify a host header for HNSC in IIS?

  4. Chris July 2, 2015 at 7:53 am - Reply

    Here’s a brain teaser for you.

    Any ideas how to make this work if your network security managers have banned wildcard certs?

    We’ve been wrestling with this, along with Microsoft, for several weeks now.

  5. pryank July 16, 2015 at 8:32 am - Reply

    Hi,
    I want to understand your DNS entries -why create an A Record for SharePoint web app and why its required for have CNAME to SharePoint web app url? and not to App Domain name?

  6. latha July 23, 2015 at 2:09 pm - Reply

    We recently hosted a Sharepoint hosted app with SSL certificate installed.

    When the app is running in UAT in app web, the web address is generating a Certificate error “mismatched address – the security certificate presented by this website us issued by a different website’s address.

    This problem might indicate an attempt to fool you or intercept any data you send to server.

    We recommend that you close this webpage”

  7. latha July 24, 2015 at 9:24 am - Reply

    yes, we are using on for main site and one for app domain.

    The main site url is [email protected] and for app it is *[email protected]

    The SSL cert is installed for [email protected] (web application) and one for *[email protected]( app catalog within same web application).

  8. latha July 24, 2015 at 9:33 am - Reply

    Here’s is what is received from L2 support team:

    “The web application

    (hr-saf-uat.xyz.net)  has already the SSL certificate installed. There is no separate IIS site will be created for Apps as it is a virtual site in the same web application.

    When we browse for Apps, SharePoint will route the request to app domain “hr-saf-appsuat.xyz.net” .

    IIS will throw a certificate error when the app request is going to different domain ie :  

    https://sharepointapps-1b217247a3b7d1.hr-saf-xyz.net which is different from web app domain https://hr-saf-uat.xyz.net

    This a tricky situation and few suggestions/discussions can be found here:

    https://social.technet.microsoft.com/Forums/windows/en-US/f5d27265-14cb-4691-9854-d032d4413011/sharepoint-2013-app-management-service-ssl-cert

     

    As per this we have to create a new web application on port 443 without host header and install the app domain certificate.

    I have already tried this, unfortunately this won’t work in our environment due to the existing site bindings.”

     

     

  9. Mark January 21, 2016 at 7:02 am - Reply

    I have tried to implement the steps in this guide on our department sharepoint site. I have followed all the steps but when I try using https after the apps do not work and I see the following in the logs:

    System.UriFormatException: Invalid URI: The hostname could not be parsed.
    at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
    at Microsoft.SharePoint.SPSite.GetHostHeaderRelativeUrlFromLookupKey(String hostHeaderLookupKey)
    at Microsoft.SharePoint.SPSite.LookupSiteInfo(SPFarm farm, Boolean contextSite, Boolean swapSchemeForPathBasedSites, Uri& requestUri, Boolean& lookupRequiredContext, Guid& applicationId, Guid& contentDatabaseId, Guid& siteId, Guid& siteSubscriptionId, SPUrlZone& zone, String& serverRelativeUrl, Boolean& hostHeaderIsSiteName, Boolean& appWebRequest, String& appHostHeaderRedirectDomain, String& appSiteDomainPrefix, String& subscriptionName, String& appSiteDomainId, Uri& primaryUri)
    at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, Boolean swapSchemeForPathBasedSites, SPUserToken userToken)
    at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, Boolean swapSchemeForPathBasedSites)
    at Microsoft.SharePoint.Administration.SPAlternateUrl.GetContextUri(HttpContext ctx)
    at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.EnsureInitialize()
    at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.BeginRequestHandler(Object oSender, EventArgs ea)
    at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    Any ideas on how to fix this would be helpful.

  10. Sharepoint Haterz March 24, 2016 at 10:10 pm - Reply

    Dang shame it took almost 2 years to find a decent how-to to make SSL apps works.

    Thanks man!

  11. read book June 25, 2016 at 5:45 pm - Reply

    Quality articles is the important to invite the viewers to visit the site, that’s what this
    site is providing.

  12. Rob August 9, 2016 at 9:18 am - Reply

    Hi, great post! this is what i’ve been looking for, except that i need to configure APPS for SP2016 on an INFOBLOX domain controller. By any chance do you know how can i go to configure particularly step 2 on an infoblox domain controller? I haven’t found anything on this topic and infoblox out there. Thanks!

  13. Torsten November 21, 2016 at 9:47 am - Reply

    Hi there,

    i’m wondering if the app web is accessible, f.ex. for cross domain library or sharepoint chrome, if the dns entry aims for the empty web application. The request for app-3fdwerwer.onfpwebapps/HostWeb/AppName hits the emtpy web app while technically the appweb is located in the onfpweb webapp.

    Kind regards

  14. Oko Djangmah June 28, 2017 at 5:02 pm - Reply

    Hi I have followed the steps you outlined and its working for me. I also created a SharePoint app and deployed to the developer site.

    The problem im having is when i click on the sharepoint app i get prompted the first time. I have to reenter my credentials after I entered it the first time in the developer site.

    Any ideas what could be the problem?

Leave A Comment