From 86d09ededefc3ab8ae47cf1662e643a03e9482c1 Mon Sep 17 00:00:00 2001 From: Shankar Date: Tue, 17 Mar 2026 21:00:25 -0400 Subject: [PATCH] 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 --- README.md | 3 ++- docs/architecture.md | 4 +++- docs/connectors.md | 1 + docs/demo-advanced.md | 7 ++++--- 4 files changed, 10 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 2e4848e..e5fbbf3 100644 --- a/README.md +++ b/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 diff --git a/docs/architecture.md b/docs/architecture.md index d92eb85..1001138 100644 --- a/docs/architecture.md +++ b/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 diff --git a/docs/connectors.md b/docs/connectors.md index 0456c37..2c34a98 100644 --- a/docs/connectors.md +++ b/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. diff --git a/docs/demo-advanced.md b/docs/demo-advanced.md index b05e954..0e8fe2e 100644 --- a/docs/demo-advanced.md +++ b/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 --> J["DigiCert API\n(planned)"] + A --> I["ADCS\n(planned)"] + A --> J["Vault PKI\n(planned)"] + A --> K["DigiCert API\n(planned)"] ``` ---