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

docs: expand V2/V3/V4 roadmap with high-value features from competitive analysis

Browse Source 
V2.0: Apache httpd, HAProxy targets, crypto policy enforcement, cert ownership
V2.1: PagerDuty/OpsGenie notifiers
V2.2: Compliance scoring
V2.3 (new): MCP server, CT Log monitoring, DigiCert issuer, filesystem discovery
V3: Restructured into discovery engine, cloud/network targets (AWS, Azure, Palo
Alto, FortiGate, Citrix, K8s), extended issuers (Entrust, GlobalSign, Google CAS,
EJBCA, Vault), ServiceNow, Ansible, compliance mapping
V4+: LDAP auth, API key scoping, multi-tenancy, Docker Secrets, Tomcat/JKS

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
shankar0123
2026-03-19 18:13:21 -04:00
parent 2e7bed9bbe
commit 393cf548b2
4 changed files with 22 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/demo-advanced.md
+8 -6
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, ADCS, 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, Entrust, GlobalSign), 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 are planned for V2; DigiCert, Vault PKI, Entrust, GlobalSign, Google CAS, and EJBCA are planned for V3.
```mermaid
flowchart TD
@@ -129,11 +129,13 @@ flowchart TD
A --> E["Local CA\n(crypto/x509)"]
A --> F["ACME\n(Let's Encrypt)"]
A --> G["step-ca\n(planned)"]
A --> H["OpenSSL / Custom CA\n(planned)"]
A --> I["ADCS\n(planned)"]
A --> J["Vault PKI\n(planned)"]
A --> K["DigiCert API\n(planned)"]
A --> G["step-ca\n(planned V2)"]
A --> H["OpenSSL / Custom CA\n(planned V2)"]
A --> I["ADCS\n(planned V2)"]
A --> J["DigiCert API\n(planned V2.3)"]
A --> K["Vault PKI\n(planned V3)"]
A --> L["Entrust / GlobalSign\n(planned V3)"]
A --> M["Google CAS / EJBCA\n(planned V3)"]
```
---