gsadmin/certctl
1
0
Fork 0
mirror of https://github.com/shankar0123/certctl.git synced 2026-06-07 12:31:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: add ADCS issuer connector to V2 roadmap

Browse Source 
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>
This commit is contained in:
shankar0123
2026-03-17 21:00:25 -04:00
parent 66f04f7afe
commit eeaf914590
4 changed files with 10 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+2 -1
View File
@@ -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
+3 -1
View File
@@ -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
+1
View File
@@ -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
+4 -3
View File
@@ -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)"]
```
---