MICROSOFT AD CS + ACME AT A GLANCE

‍

Why doesn't Microsoft AD CS natively support ACME?

Microsoft AD CS predates ACME by many years and was designed around a different certificate enrollment model.

Traditional Microsoft environments commonly rely on mechanisms such as Windows certificate auto-enrollment and certificate templates.

Modern DevOps infrastructure works differently.

Kubernetes clusters, containers, Linux systems and CI/CD pipelines increasingly expect certificate enrollment to happen automatically through standard APIs and protocols.

ACME has become one of the important protocols for that automation.

This creates a simple architectural gap:

Modern workload → ACME → ? → Microsoft AD CS

The missing layer is what organisations need to solve.

‍

Why is AD CS certificate enrollment difficult for Kubernetes?

Kubernetes commonly uses cert-manager to automate certificate issuance and renewal.

Applications declare that they need a certificate, and cert-manager handles the certificate lifecycle through a configured issuer.

The challenge is that Microsoft AD CS is not a standard native cert-manager issuer.

Organisations that want to keep AD CS as their root of trust therefore need an additional integration component.

This requirement is not new. The cert-manager community has discussed AD CS integration for years, and several community projects have been developed to bridge the gap.

‍

What are the main ways to connect Kubernetes and DevOps to AD CS?

There are three common approaches.

Let's look at each one.

‍

1. Using an ACME server in front of Microsoft AD CS

One approach is to place an ACME gateway in front of AD CS.

Applications continue using the ACME protocol they already understand. The gateway receives those requests and translates them into certificate requests that Microsoft AD CS can process.

The architecture becomes:

ACME client → ACME gateway → Microsoft AD CS

This can support clients such as:

• cert-manager
• Certbot
• acme.sh
• Linux workloads
• DevOps pipelines
• automated infrastructure

An example from the open-source ecosystem is ACME-Server-ADCS, which implements an ACME server in front of AD CS.

This approach can solve the technical integration problem effectively.

However, organisations should also consider support, maintenance, security and licensing before making a community-maintained gateway part of production PKI infrastructure.

‍

2. Using a cert-manager AD CS issuer

Another approach is to connect cert-manager more directly to AD CS through a dedicated issuer.

The original adcs-issuer project developed at Nokia enabled cert-manager to submit certificate requests to AD CS.

Community forks have subsequently continued development.

The architecture becomes:

Kubernetes → cert-manager → AD CS issuer → Microsoft AD CS

This gives Kubernetes teams a familiar certificate workflow.

However, the issuer becomes an important dependency in the certificate lifecycle.

That raises an operational question:

Who owns and maintains the integration your Kubernetes certificates depend on?

‍

3. Using SCEP with Microsoft AD CS

Not every workload speaks ACME.

Network equipment, appliances, mobile-device infrastructure and other systems may use SCEP (Simple Certificate Enrollment Protocol).

The same architectural challenge therefore appears in another form:

Device → SCEP → integration layer → Microsoft AD CS

SCEP integration allows organisations to continue using their existing Microsoft PKI while automating certificate enrollment for systems outside the traditional Windows environment.

‍

What are the risks of community-built AD CS integrations?

The issue is not that community tools are inherently insecure or poorly engineered.

Many solve their specific problem extremely well.

The risk appears when an integration becomes critical production infrastructure without the governance normally expected from critical PKI components.

This is where a technically elegant solution can become operationally fragile.

‍

Why does certificate visibility become fragmented?

Imagine an organisation using:

• Windows auto-enrollment for employee devices
• cert-manager for Kubernetes
• ACME for Linux servers
• SCEP for network appliances
• manual certificate requests for legacy applications

All certificates may ultimately come from the same Microsoft PKI.

But their enrollment and lifecycle processes now live in different places.

That makes a simple operational question harder than it should be:

Which certificates expire this month — across Windows, Kubernetes, Linux and network devices?

This is where certificate lifecycle management becomes important.

Can AD CS support ACME, SCEP and Windows certificate enrollment together?

Yes.

Organisations do not necessarily need to replace Microsoft AD CS to support modern workloads.

AD CS can remain the underlying enterprise certificate authority while additional enrollment protocols provide access for different platforms.

The challenge is maintaining central visibility and governance across those enrollment methods.

A modern enterprise environment may therefore look like this:

‍

The goal is not simply to make every enrollment path work.

The goal is to make them manageable as one certificate environment.

‍

How does certificate lifecycle management solve the AD CS protocol gap?

Certificate lifecycle management adds an operational layer between certificate consumers and the underlying PKI.

It can provide:

• certificate discovery
• central inventory
• automated enrollment
• automated renewal
• policy enforcement
• expiration monitoring
• multi-CA visibility
• ACME integration
• SCEP integration
• reporting and governance

This becomes particularly important as certificate lifetimes shorten and organisations move toward greater crypto-agility.

‍

How does CEMA connect ACME and SCEP to Microsoft AD CS?

CEMA Certificate Lifecycle Management extends Microsoft AD CS to modern workloads by providing certificate automation and enrollment capabilities across different platforms and protocols.

Instead of managing separate certificate automation islands, organisations can create a governed certificate lifecycle layer across their infrastructure.

For example:

Kubernetes / DevOps → ACME → CEMA → AD CS

Linux → ACME → CEMA → AD CS

Devices → SCEP → CEMA → AD CS

while traditional Microsoft environments can continue using their existing AD CS infrastructure.

👉  Learn more about CEMA Certificate Lifecycle Management

‍

Do organisations need to replace Microsoft AD CS?

No.

For many organisations, replacing a mature Microsoft PKI simply to support modern certificate enrollment would introduce unnecessary complexity.

A certificate lifecycle management layer can allow the organisation to retain AD CS while extending certificate automation to Kubernetes, Linux, DevOps and other environments.

This provides a migration path from:

Microsoft-centric certificate management

to:

enterprise-wide certificate lifecycle management

without requiring an immediate CA replacement.

‍

How does this support crypto-agility and PQC readiness?

Certificate automation is also becoming part of a broader crypto-agility strategy.

Organisations preparing for post-quantum cryptography need to understand and eventually change cryptographic assets across large technology environments.

Manual certificate processes make that transition considerably harder.

Central certificate lifecycle management makes it easier to:

• identify certificates
• understand where they are used
• automate replacement
• enforce policies
• change cryptographic configurations at scale

However, certificate lifecycle management is only one part of broader cryptographic discovery.

👉  Cryptographic Discovery: How to Build a PQC Cryptographic Inventory

This is a particularly strong internal link because your existing article explicitly explains that certificate lifecycle management and cryptographic discovery are complementary: discovery identifies the broader cryptographic estate, while CLM provides operational control over certificates. Geplakte tekst

👉 How to Build a PQC Migration Roadmap Your Board Can Approve

That gives you a natural topic cluster:

AD CS automation → Certificate lifecycle management → Cryptographic discovery → PQC roadmap

which is much stronger for search than isolated blog posts.

‍

The key takeaway

Microsoft AD CS can remain the foundation of an enterprise PKI even when modern workloads require ACME, SCEP and automated certificate enrollment.

The technical challenge is bridging those protocols.

The operational challenge is making sure those bridges do not create separate certificate-management silos.

Community integrations can solve individual enrollment problems effectively. As environments grow, organisations should also consider support, ownership, visibility, governance and lifecycle automation across all enrollment methods.

The objective is not simply:

“Can Kubernetes get a certificate from AD CS?”

It is:

‍“Can we manage certificates consistently across Windows, Kubernetes, Linux, DevOps and network infrastructure?”

‍

‍

-

Frequently asked questions about Microsoft AD CS and ACME

Does Microsoft AD CS support ACME?

Microsoft AD CS does not natively provide a standard ACME endpoint. Organisations typically use an integration layer, gateway or certificate lifecycle management platform to provide ACME enrollment backed by AD CS.

Can cert-manager issue certificates from Microsoft AD CS?

Yes. cert-manager can be integrated with Microsoft AD CS through third-party issuers or an ACME layer that connects cert-manager to AD CS.

Can Kubernetes use Microsoft AD CS certificates?

Yes. Kubernetes workloads can receive certificates issued by Microsoft AD CS when an appropriate enrollment or integration layer connects Kubernetes certificate automation to AD CS.

Can Linux servers use Microsoft AD CS?

Yes. Linux systems can use certificates issued by Microsoft AD CS. ACME is one way to automate enrollment and renewal for Linux workloads.

Can Microsoft AD CS work with SCEP?

AD CS environments can support SCEP-based enrollment through appropriate Microsoft or third-party enrollment infrastructure. This is commonly relevant for devices and network infrastructure.

What is an ACME gateway for AD CS?

An ACME gateway exposes an ACME-compatible interface to applications and translates certificate requests into enrollment operations that Microsoft AD CS can process.

Do I need to replace AD CS to use ACME?

No. An organisation can retain Microsoft AD CS as its certificate authority and add an integration layer that provides ACME enrollment to modern workloads.

What is the difference between ACME and certificate lifecycle management?

ACME is a protocol for automated certificate enrollment and renewal. Certificate lifecycle management is broader and includes discovery, inventory, enrollment, renewal, policy, monitoring, reporting and governance across certificates and certificate authorities.

How does CEMA work with Microsoft AD CS?

CEMA provides certificate lifecycle management and automation capabilities across heterogeneous PKI environments, allowing organisations to extend certificate management beyond traditional Windows enrollment processes.

‍