1

We have an on-prem configuration of SharePoint 2016 and Remote Web to host Addins (also on-prem). Configuration is high-trust. Our SharePoint domain is testab.com. Web Apps (or sites) will use abtest.com as their domain or url. Obviously these domain names are not actual, but should depict what we're trying to do.

Regarding setting up Certificate for SharePoint and Addin server - is it okay to have the cert issued to abtest.com domain even though the SharePoint servers domain is testab.com? If not, what will work - knowing SharePoint domain is what it is and public url needs to be abtest.com?

We are currently getting a Mismatched Address Certificate error.

1

Your standard SharePoint Web Apps (where users interact with SharePoint) would need to have a matching certificate for them, either via wildcard, SAN, or single host certificates. These would be bound to the IIS site(s) of your Web Application(s).

For your App domain, you need another Web Application with no host header. You also need a matching wildcard certificate (e.g. *.exampleapps.com) that is bound to the IIS site. Note that the wildcard must match, e.g. if your apps domain is apps.example.com, a *.example.com wildcard certificate will not work; you need *.apps.example.com instead.

Your server where the addin is running must also have a certificate that covers the FQDN for the addin's website.

1

To clarify this a little bit more.

  1. Certificate subject or SAN have to be the same as your domain name or in the case of wildcard certificates have to cover (as Trevor explained), your domain. So, no you cannot use certificate issued for testab.com in abtest.com.
  2. As I understand, in your case abtest.com is not SharePoint App Domain. It is just Web Site hosting Add-Ins. So, you don't need wildcard certificate for this domain. App Domain is something different, and it is not needed forprovider hosted Add-Ins at all. App Domain can be usefull in some scenarios, and is necessary for SharePoint hosted Add-Ins.
  3. You can assign certificates in IIS only and, if you use the same IP address, but different certificates hosted on the same IIS, you need to enable SNI. The good example can be web application hosting mysites/onedrvie and the second one hosting portal, team sites etc.
  4. Don't use self-signed certificates. They are quite difficult to be managed and properly distributed.
  5. Please make sure the servers storing root CRT and CLRs are accessible from SharePoint servers or you get some interesting issues. And most 'workarounds' does not really work. They bring just more issues.
  6. You need also certificate(s) for SharePoint servers for services communication. One important thing is to issue certifcate for both short server name and FQDN as some services use short names and other FQDN.
  7. You probably need help from guy who understand how to issue proper certificates and use proper certificate templates for them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.