One 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:
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?)
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:
2a. If they are not already created, then create two new Forward Lookup Zones for your site and app domain:
2b. Create an ‘A’ record for your SharePoint site. (It is “mytestsite.onfpweb.net” in my example):
2c. Create a wildcard CNAME record for your app domain that points to your site URL
(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):
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.
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:
(Screenshot showing that there are no site collections in the app domain placeholder web application)
(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).
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:
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.
Hope that helped! Thanks for reading!
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:
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.
2a. If they are not already created, then create two new Forward Lookup Zones for your site and app domain:
2b. Create an ‘A’ record for your SharePoint site. (It is “mytestsite.onfpweb.net” in my example):
2c. Create a wildcard CNAME record for your app domain that points to your site URL
(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):
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: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.
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:
(Screenshot showing that there are no site collections in the app domain placeholder web application)
(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).
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:
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.
Hope that helped! Thanks for reading!
No comments:
Post a Comment