Publishing SharePoint-Hosted App Error

Question

I've written a SharePoint-Hosted app that works in a simple Dev environment, but when I add it to a catalog on a full farm I get an error about a security certificate.

"Content was blocked because it was not signed by a valid security certificate.

For more information, see “About Certificate Errors” in Internet Explorer Help."

Does Kerberos on the web apps in the farm cause this?

Answer 1

If your SharePoint site is using SSL,

Have you configured DNS and SSL for SharePoint 2013 Apps?

If No, then follow below steps for that.

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:

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!