Documentation | CertSecure

Azure Key Vault Setup Guide

This section serves as a guide for the prerequisite configuration required for the integration of Azure Key Vault with CertSecure Manager.

Prerequisites

Detailed Configuration Steps

A system administrator with the necessary permissions must perform the following tasks:

STEP 1: Register an App in Microsoft Entra ID (Azure AD)

Go to Microsoft Entra ID > App registrations.
Click “New registration”.
- Name: CertSecure_Manager_AKV
- Supported account types: Single tenant
- Leave Redirect URI empty (not needed).
Click Register.

STEP 2: Generate a Client Secret

Open your registered app → go to Manage > Certificates & secrets.
Under Client secrets, click New client secret.
- Give it a name like AKVTesting
- Choose an expiration (e.g., 6 months or 12 months).
- Click Add.
After saving, copy the secret value immediately (you won’t see it again!).

STEP 3: Note the Following Values

You'll use these during registration with CertSecure Manager:

Name	Where to find
Tenant ID	In Overview under “Directory (tenant) ID”
Client ID	In Overview under “Application (client) ID”
Client Secret	From step 2

STEP 4: Assign Access to Key Vault

Using Role-Based Access Control (RBAC)

Go to your Key Vault in the Azure Portal.
Navigate to Access control (IAM) → Click Add > Add role assignment.
Role: Choose Key Vault Certificates Officer
Assign access to:
- User, group, or service principal → Search for your app name (e.g., CertSecure_Manager_AKV_Test)
Click Review+assign.

Using Access Policy

Go to your Key Vault in the Azure Portal.
In the left menu, select Access policies.
Click + Add Access Policy.
In Permissions, under Certificate permissions, check: Get, List, and Import.
Select Principal (your app).
Click Review+create.

Full Prerequisite Checklist

The following consolidated checklist covers every prerequisite for the Azure Key Vault integration, grouped by area. Use it to confirm readiness before registering a vault, or to work through in order when isolating the cause of a failure.

Azure AD (Identity)

App Registration (service principal) exists with a valid, non-expired client secret.
tenant_id, client_id, client_secret are correct and match the target tenant.

Key Vault Permissions

Service principal has Certificate permissions on the vault: get, list, import (via Access Policy or RBAC role Key Vault Certificates Officer).
environment field ("commercial" vs "government") matches the vault’s actual cloud

Network — Azure AD

Outbound HTTPS (443) to login.microsoftonline.com (commercial) or login.microsoftonline.us (government).
That allowlist covers the whole host, not just a tenant-scoped path

Network — Key Vault

Outbound HTTPS (443) to <vault_name>.vault.azure.net (commercial) or .vault.usgovcloudapi.net (government).
If the vault restricts network access (Selected networks / Private Endpoint), the backend’s outbound IP or VNet path is explicitly allowed on the vault’s Networking blade.

Network Hygiene / Infrastructure

System clock is accurate (NTP working) — clock drift causes token nbf/exp validation failures that masquerade as auth/network errors.
If firewalling by IP/CIDR instead of FQDN: use and periodically refresh the AzureActiveDirectory and AzureKeyVault service tag ranges (Microsoft rotates these).

CertSecure Manager

Acting user has ‘Manage Azure Key Vaults’ in their Administrator permissions.
vault_name is unique (registration rejects duplicates).
departments set correctly at registration — gates non-admin visibility/access.

Troubleshooting

When something fails, work through these checks in order:

DNS resolves both hosts (login.microsoftonline.com, <vault>.vault.azure.net).
TCP 443 is reachable to both.
An unauthenticated HTTPS call returns 400/401 (not a timeout) from both.

For integration steps, refer to the Utilities > Azure Key Vault section in the CertSecure Manager documentation. The documentation can be accessed from the CertSecure Manager UI.

CertSecure Manager Documentation menu

On this Page: