Picture this: You’ve registered an application in Azure to support your Power Platform or Dynamics 365 solution. Now you need to authenticate that app – either by generating a client secret or by using a certificate.
I’m not talking about service principals for third-party integrations. This is about apps you’ve built yourself – for flows, custom connectors, or other platform-specific scenarios.
So here’s the real question:
Where should you store your client secret? Or better yet – how and where do you create and manage a certificate securely?
In this article, we’ll focus exclusively on the certificate approach – why it’s the more secure option, and how to do it right.
Why You Shouldn’t Generate Self-Signed Certificates Locally with PowerShell
While it might be tempting to quickly spin up a self-signed certificate using PowerShell on your local machine, this approach introduces several risks:
- Lack of centralized management: Locally generated certificates are harder to track, rotate, and revoke – especially in team environments or production scenarios.
- Security concerns: Storing private keys on developer machines increases the risk of compromise, especially if those machines aren’t hardened or centrally monitored.
- No automated lifecycle: Certificates created manually don’t benefit from automated expiration alerts, renewal workflows, or access controls.
Why Azure Key Vault Is the Right Choice
Azure Key Vault is purpose-built for managing secrets, keys, and certificates securely. Here’s why it’s the recommended approach:
Automated renewal: If you use Key Vault you can automate certificate renewal and reduce downtime risk.
Centralized certificate lifecycle management: You can create, import, renew, and delete certificates – all from a single, secure location.
Access control and auditing: Key Vault supports granular access policies and integrates with Azure Monitor for logging and alerting.
However, this approach does come with some cost. You can view the most up-to-date pricing details on the official Microsoft Azure Pricing page.
So, How Do You Get Started?
The setup of an Azure Key Vault will be described in another blog post. But once your Key Vault is created, here’s how to begin working with certificates:
- Navigate to your Key Vault in the Azure Portal.
- In the left-hand navigation pane, select Certificates.
- From here, you can:
- Generate a new certificate using an integrated certificate authority.
- Import an existing certificate (e.g., from your internal PKI or a third-party CA).
In this scenario, we’ll generate a new certificate. To get started, click on “Generate/Import.”
Once selected, an input interface will appear, prompting you to fill in the following details:
- Certificate Name: Provide a clear, descriptive name to easily identify the certificate’s purpose.
- CA: Choose Self-signed Certificate. This option is ideal for internal applications, as it’s more cost-effective than using an official Certificate Authority.
- Subject: Microsoft recommends using the format
CN=CompanyName, as shown in the tooltip. I suggest following this guidance.
For all other fields, the default settings are generally sufficient and can be left unchanged.
After clicking Save, the certificate will be generated and ready for use. To complete the Azure App Registration process, you’ll need to download the certificate in either PFX or PEM format. Once downloaded, upload it to the appropriate application registration as a certificate credential.
Bonus: How to implement it into Power Automate
If you need to retrieve a credential or secret key, you can use the Power Automate action “Get secret” from the Azure Key Vault connector. Setting it up is straightforward: simply use the action and select the relevant Secret Name from the list -this includes certificates, secrets, and keys that are stored in the vault.
Use a certificate in the HTTP-Action
If you want to use the certificate in an HTTP action—as demonstrated in the previous blog post—you’ll need to update the following settings after retrieving the certificate via the “Get Secret” action:
- Authentication Type:
Active Directory OAuth - Tenant: Enter the Tenant ID from the App registration.
- Audience: Use your SharePoint base URL, e.g.,
https://yourcompanyname.sharepoint.com - Client ID: Provide the Client ID (App ID) shown in the App registration.
- Credential Type:
Certificate - PFX: Use the Body value from the “Get Secret” action.
- Password: Not required for this configuration.
This article was crafted with the support of AI to deliver clear, professional English while staying true to the original technical insights.