Development environment for low-trust apps: Configuring and using SSL

SSL/HTTPS is a required step for most SharePoint installations and deployments. The entire web community is moving towards secure communications. However, I still see most development environments set up using HTTP only and I still see many issues when moving to test and production environments, such as mixed content blocking. In this case, the browser will not load resources such as data sources, scripts, CSS files and images as they are in HTTP while the main page is in HTTPS. As we want to develop using scenarios that are as close as possible to production so that we can test for issues before deploying then we should set up all environments for SSL.

This post is in the article series “Development environment for low-trust” where we aim to set up an environment that replicates a live production environment as closely as possible. Here, we also switch from High Trust apps to Low Trust apps to support ADFS, Azure AD and future-proof app/add-in models.



I have had a huge amount of discussions on certificates throughout the years and here is a quick rundown on a few of them.
“can we use self signed certificates”?
You can use a self-signed certificate as long as you can control all clients that access the environment. For example, if the local machine is the only one that will access the site, then the machine can sign its own certificates. However, if you are using a multi-server farm then you should sign the certificates from a domain controller, as all servers and clients in the domain will then trust the certificates. If an external machine is using the server then we can deploy the root certificate to those machines; if you have 5 external test machines then this may be much better than paying for public certificates. You must weigh in the cost vs the additional admin time.
“how much do they cost”?
People pay crazy amounts for certificates. I’ve heard reasoning such as “these certificates are of higher quality than those” and personally don’t believe it but hey, I’m no real security geek. For my money, I use GoDaddy as they have near unbeatable pricing.
“how do wildcards work”?
A wildcard certificate is great when using subdomains as you can use the same certificate for many services. On the downside, if the certificate is compromised then all sites are compromised. In my opinion, wildcards are great and are also required when using low-trust apps in a SharePoint environment.
Note that wildcards can only support one subdomain level. For example, the certificate * can support, and but will not work for as I then need a wildcard certificate for *


An SSL certificate can be revoked by the certification authority. This means that the certificate was in trial or that the certificate has been invalidated due to legal reasons. For this to work, the machine will visit the certification to ensure that the certificate is valid and this causes a delay.
When your server is within a DMZ then the revocation will not complete successfully and this can cause issues on load start, adding minutes of extra startup and latency. In this case, we should disable revocation check locally for those servers.
To disable CRL checking machine-wide, go to Control Panel -> Internet Options -> Advanced -> Under security, uncheck the Check for publisher's certificate revocation option.
To disable CRL checking for IIS, update the registry and set [Dword] DefaultSslCertCheckMode=1 at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo\]DefaultSslCertCheckMode=1. Then Reboot the box for the changes to take into effect.
This can be a very long discussion, so for all your options of disabling CRL, such as on client machine, domain or server level, see instead

Setting up SSL

The easiest way to set up a development environment is to issue wild-card certificates for your environment. In this case, we need:

  • One wild-card certificate for your development domain, i.e. SharePoint and low-trust apps. In my case, *
  • One wild-card certificate for your SharePoint-hosted apps. In my case *

There are recommendations out there that, for security reasons, you should use a separate top domain for apps. I have no opinion either way on security so I use what is most cost efficient. You could create a separate subdomain for low-trust apps as well but this is my setup as it saves time and money and still gives me good security. You could use standard, non-wildcard certificates for your SharePoint sites but you need at least one wildcard for your SharePoint hosted apps.
I issue these certificates from my domain controller by:

  1. Enable certificate services on the server. Follow step 1-9 in
  2. Ensure web certificate templates are available
    1. Start Certification Authority on the domain controller
    2. Expand the tree, check if Web service template displays under Certificate Templates
    3. If not, right-click Certificate Templates, click New -> Certificate Templates to Issue, and add the Web Server template
    4. Make sure Authenticated Users has Read permission on the Web Server template
  3. Request new certificate for each desired cert
    1. Start local machine certificates
    2. Expand Personal –> Certificates, then right-click and select All Tasks… –> Request New Certificate
    3. Click Next, Next (choosing Active Directory Enrollment Policy) then under Web Server, click the link “Click here to configure settings”
    4. On the Subject Tab click on the Type dropdown box and choose Common Name and under value put in a wildcard asterisk followed by your domain name (so mine would be * and later on * then click “Add.”
    5. Go to the tab Private Key and expand Key Options and check “Make private key exportable” then click OK
    6. Now check the Web Server box and select Enroll. When done, click Finish.
    7. Right-click your new certificate and choose All Tasks… –> Export
    8. Click Next, selet Yes to export the private key, click Next and specify a password, click until asked to specify a name. Name it (for example, and click Next then Finish
    9. Copy the certificate to all WFE and/or app/add-in servers
    10. Open local machine certificates on the WFE/app/add-in server
    11. Expand Personal –> Certificates, then right-click and select All Tasks… –> Import…
    12. Import the certificate into the Personal folder of the local computer

I then bind these SSL certificates to the app. To do this, I use an extended web application and bind my certificate to the app by

  1. Open IIS Manager
  2. Select the extended web application node and click “Bindings” in the right hand toolpane
  3. Add a binding on https and All Unassigned IP addresses on port 443, add the name of your SharePoint site (such as as Host Name then check “Require Server Name Indication”
  4. Add a new binding on https and All Unnasigned IP addresses on port 443, do not specify a name and choose the SPAPPS wildcard certificate

Note that IIS will not save entries if they conflict with other web application bindings so make sure there are no conflicts. Some issues can be resolved by temporarily moving a binding to a non-standard port such as 81 or 444.
I also set up SSL binding for Central Administration and low trust apps using the same wildcard certificate (* Here is my list of web applications and their bindings (protocol, IP, port and certificate):

  • SharePoint (80)
    • http, *, 80
  • SharePoint Central Administration v4
    • https, *RSNI, 443, *
  • SharePoint (443)
    • https, *RSNI, 443, *
    • https, *, 443, *
  • Apps (per each app)
    • https, *RSNI, 443, *

If you are building a large amount of apps then you can, for the sake of making IIS management easier, consolidate apps into one backend or using virtual directories for your apps.

Speed issues and SSL termination

Using SSL on multiple levels, on server and on load balancer, will cause heavy latency issues in your deployment. This is not an issue in a development environment but will be an issue in a real deployment. SSL termination will help with this and I recommend using it on your test, UAT and production environments.
For more info on SSL speed issues, see