SSL certificates in multi-tenant app registration

%3CLINGO-SUB%20id%3D%22lingo-sub-443142%22%20slang%3D%22en-US%22%3ESSL%20certificates%20in%20multi-tenant%20app%20registration%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-443142%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3EWe're%20developing%20a%20managed%20app%20that%20will%20be%20deployed%20to%20multiple%20tenants.%20The%20solution%20will%2C%20among%20other%20things%2C%20work%20with%20SharePoint%20sites%20on%20the%20end%20users'%20tenant.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20looked%20into%20using%20a%20single%20multi-tenant%20app%20registration%20with%20the%20appropriate%20rights.%20Because%20of%20security%20restrictions%20on%20the%20SharePoint%20API%20when%20using%20Azure%20app-only%2C%20a%20certificate%20must%20be%20added%20to%20the%20app%20registration%20and%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsharepoint%2Fdev%2Fsolution-guidance%2Fsecurity-apponly-azuread%23setting-up-an-azure-ad-app-for-app-only-access%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ethe%20PFX%20must%20be%20provided%20in%20all%20API%20calls%3C%2FA%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20wish%20to%20have%20as%20little%20data%20at%20our%20end%20as%20possible%2C%20so%20the%20we%20hoped%20to%20include%20the%20application%20that%20connects%20to%20SharePoint%20as%20part%20of%20the%20deployment.%20However%2C%20this%20would%20lead%20to%20multiple%20apps%20connecting%20to%20SharePoint%20using%20the%20same%20PFX.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20wondering%20if%20there%20is%20a%20better%20way%20to%20go%20about%20this.%20Must%20the%20connecting%20web%20app%20instead%20be%20hosted%20on%20our%20end%3F%20Is%20there%20a%20safe%20way%20of%20storing%20the%20PFX%20in%20multiple%20locations%2C%20or%20make%20it%20accessible%20to%20multiple%20tenants%3F%20It%20is%20important%20to%20us%20that%20we%20can%20automate%20the%20process%20as%20well%2C%20preferrably%20using%20ARM%20or%20an%20automation%20job%20as%20part%20of%20the%20deployment%20...%20At%20the%20very%20least%2C%20I%20would%20be%20thankful%20for%20suggestions%20on%20making%20any%20configurations%20relatively%20pain-free%20for%20the%20end%20user.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPS%3A%20We%20would%20like%20to%20avoid%20the%20use%20of%20service%20user%20accounts.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-443142%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20Active%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EIdentity%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
New Contributor

Hello,

We're developing a managed app that will be deployed to multiple tenants. The solution will, among other things, work with SharePoint sites on the end users' tenant.

 

We have looked into using a single multi-tenant app registration with the appropriate rights. Because of security restrictions on the SharePoint API when using Azure app-only, a certificate must be added to the app registration and the PFX must be provided in all API calls.

 

We wish to have as little data at our end as possible, so the we hoped to include the application that connects to SharePoint as part of the deployment. However, this would lead to multiple apps connecting to SharePoint using the same PFX.

 

I'm wondering if there is a better way to go about this. Must the connecting web app instead be hosted on our end? Is there a safe way of storing the PFX in multiple locations, or make it accessible to multiple tenants? It is important to us that we can automate the process as well, preferrably using ARM or an automation job as part of the deployment ... At the very least, I would be thankful for suggestions on making any configurations relatively pain-free for the end user.

 

PS: We would like to avoid the use of service user accounts.

0 Replies