Secure Certificate provisioning in azure CA Infrastructure

Question

Secure Certificate provisioning in azure CA Infrastructure

Radhabai Patel 0

Secure Certificate Provisioning in Azure with Minimal CA Dependency

What are the recommended approaches for implementing scalable and secure certificate provisioning in Azure while reducing reliance on traditional Certificate Authority (CA) infrastructure? How can this solution be securely adopted across various workloads and services with PKI, KV and Infra Hitel?

Marcin Policht 112.6K MVP Volunteer Moderator

This is a really broad topic - here is its fairly comprehensive overview:

Use Microsoft Cloud PKI. Microsoft Cloud PKI is a cloud-native, Microsoft-managed PKI service integrated with Microsoft Intune and Microsoft Entra ID.

Benefits:

Fully cloud-based certificate authority, managed by Microsoft.
Issues certificates for user and device authentication, Wi-Fi/VPN access, and more.
No need to deploy or maintain on-prem ADCS or NDES.
Supports certificate auto-renewal and lifecycle management via Intune.

Use Cases:

Device authentication to Wi-Fi or VPN.
Certificate-based user authentication.
Securing hybrid and remote endpoints.

Integration:

Enroll certificates using PKCS or SCEP profiles via Intune.
Entra ID groups and conditional access can scope certificate issuance and usage.

Replace on-prem CA-backed authentication with Entra ID certificate-based authentication (CBA). CBA enables secure user authentication without relying on Active Directory or smart card infrastructure.

Benefits:

Native support for certificate authentication in Microsoft Entra ID.
Integrates with Conditional Access, MFA, and SSO.
Works with certificates issued by Microsoft Cloud PKI, Intune-integrated third-party CAs, or your existing CA (if needed).

Use Cases:

High-assurance login scenarios (e.g., government, financial).
Passwordless authentication initiatives.
Zero trust enforcement.

Manage TLS/SSL certs with Azure Key Vault and Automation. Azure Key Vault provides secure storage and lifecycle automation for TLS certificates used across Azure services.

Recommended Practices:

Use Azure Key Vault to store certificates securely with HSM-backed keys.
Use public CA integrations (e.g., DigiCert) to enable automatic renewal.
Automate deployment to App Service, Azure Front Door, or Application Gateway using ARM/Bicep, Terraform, or CI/CD pipelines.

For Kubernetes (AKS):

Use cert-manager with Azure Key Vault or a supported CA backend.
Combine with Workload Identity Federation for secure access to Key Vault.

Use Intune certificate profiles for endpoint certificate deployment. Microsoft Intune supports distributing certificates via:

PKCS (direct certificate issuance with private key provisioning)
SCEP (for bulk device provisioning, typically with NDES)

Modernized Approach:

Use Microsoft Cloud PKI as the issuing CA via Intune.
Decommission on-prem NDES or legacy CA integrations.
Intune also supports third-party CAs (e.g., Entrust, DigiCert, Sectigo) if needed.

Implement certificate lifecycle automation. Automate certificate issuance, renewal, and deployment to avoid manual overhead and reduce operational risk.

Tools:

Azure CLI, PowerShell, or REST APIs to manage Key Vault certs.
GitHub Actions, Azure DevOps, or Terraform for pipeline automation.
For Kubernetes, use cert-manager with automatic DNS or HTTP-01 validation.

Application and workload integration

Workload	Certificate Strategy	On-Prem CA Required
Web apps (HTTPS)	Azure Key Vault + Public CA	No
AKS workloads (mTLS, ingress)	cert-manager + Azure Key Vault or 3rd-party CA	No
Device/VPN/Wi-Fi auth	Microsoft Cloud PKI via Intune	No
Client auth to Microsoft 365	Entra ID Certificate-Based Authentication	No
IoT device provisioning	Azure IoT Hub + X.509 certificates	No
Dev/test certs	HashiCorp Vault, Azure DevOps, Self-signed	Optional

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Radhabai Patel 0 Reputation points

2025-07-19T17:44:14.5233333+00:00

thanks , yes I know this is a broad topic so how does Keyvaut, Azure AD fits in and any other components, as we have many CA on prem services globally, want to adopt in to Azure with less interactions with onprem CA's

2 answers

Your answer

Radhabai Patel 0 Reputation points

2025-07-19T17:44:14.5233333+00:00

thanks , yes I know this is a broad topic so how does Keyvaut, Azure AD fits in and any other components, as we have many CA on prem services globally, want to adopt in to Azure with less interactions with onprem CA's

Answer 1

You’ll need to redesign your architecture around Microsoft Cloud PKI, Microsoft Entra ID, Azure Key Vault, and optionally Intune and cert-manager (for workloads like Kubernetes). The following should help:

Key Azure components and their roles in modern certificate provisioning

Azure Component	Role	Replaces / Minimizes
Microsoft Cloud PKI	Microsoft-hosted root and issuing CAs for device/user certificates	On-prem ADCS CA, Global CA hierarchy
Microsoft Entra ID	Provides certificate-based authentication (CBA), identity federation, policy enforcement	On-prem AD DS for CBA
Azure Key Vault	Secure storage and lifecycle management of TLS/SSL certificates	Windows CA cert stores, internal vaults
Intune	Certificate deployment to devices and endpoints via SCEP/PKCS profiles	GPO/SCCM deployment of certs
cert-manager	Automates cert issuance/rotation in Kubernetes workloads	Manual cert provisioning in clusters
Azure Application Gateway / Front Door	Terminates TLS using certificates from Key Vault	IIS/Apache/Nginx with manually loaded certs
GitHub Actions / Azure DevOps	Automates certificate workflows (request, renew, deploy)	Manual or script-based cert handling

At a high level, you can consider modern certificate architecture in Azure to consist of:

Root/issuing CA: Microsoft Cloud PKI

Acts as the central authority for issuing certificates.
You no longer need to operate offline roots or intermediate CAs across geographies.
Managed lifecycle, highly available, and integrates with Intune.
Policies and template-like configurations for issuance control.

Certificate storage and delivery: Azure Key Vault

TLS/SSL certificates used by workloads are stored securely in Azure Key Vault.
Integration with services:
- App Services, App Gateway, Front Door, AKS via Ingress
Supports:
- Automatic renewal from public CAs.
- Import of certificates issued from Microsoft Cloud PKI (for internal use).

Authentication and authorization: Microsoft Entra ID

Enforces certificate-based auth for users and devices.
Replaces reliance on smart cards, ADFS, or on-prem CBA setups.
Conditional Access policies can be tied to cert usage.
Works with certificates issued by Microsoft Cloud PKI or your existing CA (if federated).

Device enrollment and cert deployment: Intune

Pushes certs to managed endpoints (Windows, macOS, iOS, Android).
Supports PKCS (direct cert issuance) and SCEP (for larger scale provisioning).
Fully integrated with Microsoft Cloud PKI, no on-prem NDES or connector required.

Kubernetes / Service Mesh / Internal TLS: cert-manager

For AKS or other Kubernetes workloads:
- Use cert-manager to request and renew certs.
- Backed by Azure Key Vault or a custom CA (e.g., Microsoft Cloud PKI).
Supports automation for Ingress and internal services (mTLS).

To transition strategy from on-prem CAs

Step 1: Inventory and categorize

List all current CAs, their issuing scope, and dependencies.
Categorize certs by purpose:
- TLS/SSL
- Device/User Auth
- Wi-Fi/VPN
- Internal app-to-app communication

Step 2: Pilot Microsoft Cloud PKI

Start with a region or business unit.
Configure Microsoft Cloud PKI as the issuing CA.
Use Intune to distribute certificates to pilot users/devices.
Use Entra CBA for login testing.

Step 3: Migrate TLS/SSL to Azure Key Vault

Start with public-facing workloads.
Migrate cert storage to Key Vault.
Automate provisioning using Key Vault + Azure CLI or public CA integration.

Step 4: Retire on-prem CA dependencies

Once new certs are issued and trusted, revoke old CA-issued certs.
Retire NDES connectors, offline roots, and intermediate CAs not needed.
Document trust changes and update clients where necessary.

Step 5: Automate lifecycle

Implement GitHub Actions, Azure DevOps, or similar to automate:
- Cert issuance
- Key Vault updates
- Deployment to services (via API/IaC)

If you cannot fully eliminate on-prem CAs right away:

Bridge approach: Continue issuing certain certs from on-prem CAs but store them in Azure Key Vault.
Use Intune with SCEP connector (on-prem or cloud-hosted) as a bridge.
Configure trust relationships between on-prem CAs and Microsoft Entra ID temporarily.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Radhabai Patel 0 Reputation points

2025-07-19T19:34:13.62+00:00

thanks for the update
Radhabai Patel 0 Reputation points

2025-07-19T19:36:49.7666667+00:00

Is it possible you can upload a detailed design diagram for my understanding, singapore location
Marcin Policht 112.6K Reputation points MVP Volunteer Moderator

2025-07-19T20:19:46.84+00:00

In short no - but you should be able to follow the information I provided in your project

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more