docs: add ADCS issuer connector to V2 roadmap

Active Directory Certificate Services (ADCS) added as a planned
issuer connector across README, architecture, connectors, and
demo-advanced docs. Requested by community feedback.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

README.md

@@ -280,6 +280,7 @@ GET    /ready                             Readiness check
 | ACME v2 (Let's Encrypt, Sectigo) | Implemented (HTTP-01) | `ACME` |
 | step-ca | Planned (V2) | — |
 | OpenSSL / Custom CA | Planned (V2) | — |
+| ADCS (Active Directory CS) | Planned (V2) | — |
 | Vault PKI | Planned | — |
 | DigiCert | Planned | — |
 
@@ -351,7 +352,7 @@ All nine development milestones (M1–M9) are complete. The backend covers the f
 Remaining before the v1.0.0 tag: dashboard screenshots in README, tagged Docker images published, final error-handling audit to confirm no panics or unhandled error paths.
 
 ### V2: Operational Maturity
-- **V2.0: Operational Workflows** — ACME DNS-01 challenges (wildcard certs, custom validation scripts), step-ca and OpenSSL/custom CA issuer connectors, F5 BIG-IP and IIS target connector implementations, renewal approval UI, bulk cert operations, deployment timeline, real-time updates (SSE/WebSocket), target config wizard
+- **V2.0: Operational Workflows** — ACME DNS-01 challenges (wildcard certs, custom validation scripts), step-ca, ADCS, and OpenSSL/custom CA issuer connectors, F5 BIG-IP and IIS target connector implementations, renewal approval UI, bulk cert operations, deployment timeline, real-time updates (SSE/WebSocket), target config wizard
 - **V2.1: Team Adoption** — OIDC/SSO, RBAC, CLI tool, Slack/Teams notifiers, bulk cert import
 - **V2.2: Observability** — expiration calendar, health scores, Prometheus metrics, deployment rollback
 

docs/architecture.md

@@ -42,7 +42,8 @@ flowchart TB
         CA2["ACME\n(Let's Encrypt)"]
         CA3["step-ca\n(planned)"]
         CA4["OpenSSL / Custom CA\n(planned)"]
-        CA5["Vault PKI\n(planned)"]
+        CA5["ADCS\n(planned)"]
+        CA6["Vault PKI\n(planned)"]
     end
 
     subgraph "Target Systems"
@@ -349,6 +350,7 @@ flowchart TB
         II --> ACME["ACME v2"]
         II --> SC["step-ca (planned)"]
         II --> OC["OpenSSL / Custom CA (planned)"]
+        II --> AD["ADCS (planned)"]
         II --> VP["Vault PKI (planned)"]
     end
 

docs/connectors.md

@@ -126,6 +126,7 @@ The following issuer connectors are planned for V2:
 
 - **step-ca** — Smallstep's private CA and ACME server. Would allow certctl to issue certificates from a self-hosted step-ca instance via its ACME or provisioner APIs.
 - **OpenSSL / Custom CA** — Support for external CAs that use OpenSSL-based signing workflows, including custom script hooks for organizations with existing CA tooling.
+- **ADCS (Active Directory Certificate Services)** — Microsoft's enterprise CA. Would allow certctl to request certificates from an existing ADCS infrastructure, useful for organizations that need lifecycle management around their Windows PKI.
 - **Vault PKI** — HashiCorp Vault's PKI secrets engine for organizations using Vault as their internal CA.
 - **DigiCert** — Commercial CA integration via DigiCert's REST API.
 

docs/demo-advanced.md

@@ -116,7 +116,7 @@ You should see:
 
 The result is a structurally valid X.509 certificate — browsers won't trust it (no root CA in their trust store), but it exercises the exact same code paths that a production ACME or Vault issuer would.
 
-**Why pluggable issuers:** Different organizations use different CAs. Some use Let's Encrypt (ACME protocol), some use step-ca or internal PKI (Vault, ADCS), some use commercial CAs (DigiCert, Sectigo), and some have custom OpenSSL-based workflows. The connector interface means certctl doesn't care — it calls `IssueCertificate()` and gets back a signed cert regardless of the backend. V1 ships with Local CA and ACME (HTTP-01); step-ca, OpenSSL/custom CA, Vault PKI, and DigiCert are planned for V2.
+**Why pluggable issuers:** Different organizations use different CAs. Some use Let's Encrypt (ACME protocol), some use step-ca or internal PKI (Vault, ADCS), some use commercial CAs (DigiCert, Sectigo), and some have custom OpenSSL-based workflows. The connector interface means certctl doesn't care — it calls `IssueCertificate()` and gets back a signed cert regardless of the backend. V1 ships with Local CA and ACME (HTTP-01); step-ca, ADCS, OpenSSL/custom CA, Vault PKI, and DigiCert are planned for V2.
 
 ```mermaid
 flowchart TD
@@ -131,8 +131,9 @@ flowchart TD
     A --> F["ACME\n(Let's Encrypt)"]
     A --> G["step-ca\n(planned)"]
     A --> H["OpenSSL / Custom CA\n(planned)"]
-    A --> I["Vault PKI\n(planned)"]
+    A --> I["ADCS\n(planned)"]
-    A --> J["DigiCert API\n(planned)"]
+    A --> J["Vault PKI\n(planned)"]
+    A --> K["DigiCert API\n(planned)"]
 ```
 
 ---