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

docs: cross-validate all documentation against codebase, fix 21 inaccuracies

Browse Source 
Fact-checked every doc file against actual source code. Key corrections:
- Table count 14→17 (added profiles, agent_groups, agent_group_members)
- Endpoint count 55→68 (counted from router.go)
- Test count 250+→330+ (99 service + 165 handler + 53 frontend + connectors)
- Dashboard views 14→16 pages (counted from web/src/pages/)
- step-ca marked implemented (was "Planned V2") across all docs
- ACME DNS-01 marked implemented (was "planned") in concepts.md
- Removed ADCS as separate planned connector (handled via sub-CA mode)
- Fixed pointer types in connectors.md interface docs (*string, *time.Time)
- Added 3 missing tables to architecture.md ER diagram
- Added 5 missing env vars to README config table
- Updated M11/M12 to ✅ in README roadmap
- Issuer count in quickstart demo data 3→4 (added step-ca)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
shankar0123
2026-03-21 23:12:23 -04:00
parent f5fed74d6f
commit aa183efdca
6 changed files with 64 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/demo-advanced.md
+3 -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), some use commercial CAs (DigiCert, Entrust, GlobalSign), and some have custom OpenSSL-based workflows. For enterprises with ADCS, certctl can operate as a sub-CA — all issued certs chain to the enterprise root. 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 (self-signed or sub-CA) and ACME (HTTP-01); step-ca, OpenSSL/custom CA are planned for V2; DigiCert, Vault PKI, Entrust, GlobalSign, Google CAS, and EJBCA are planned for V3.
**Why pluggable issuers:** Different organizations use different CAs. Some use Let's Encrypt (ACME protocol), some use step-ca or internal PKI (Vault), some use commercial CAs (DigiCert, Entrust, GlobalSign), and some have custom OpenSSL-based workflows. For enterprises with ADCS, certctl can operate as a sub-CA — all issued certs chain to the enterprise root. 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 (self-signed or sub-CA), ACME (HTTP-01 + DNS-01 for wildcards), and step-ca (Smallstep private CA via native /sign API). OpenSSL/Custom CA is planned for V2; DigiCert, Vault PKI, Entrust, GlobalSign, Google CAS, and EJBCA are planned for V3.
```mermaid
flowchart TD
@@ -129,7 +129,7 @@ flowchart TD
A --> E["Local CA\n(self-signed or sub-CA)"]
A --> F["ACME\n(Let's Encrypt)"]
A --> G["step-ca\n(planned V2)"]
A --> G["step-ca\n(implemented)"]
A --> H["OpenSSL / Custom CA\n(planned V2)"]
A --> J["DigiCert API\n(planned V2.3)"]
A --> K["Vault PKI\n(planned V3)"]
@@ -501,7 +501,7 @@ flowchart TB
end
subgraph "Data Store"
PG["PostgreSQL 16\n14 tables, TEXT PKs"]
PG["PostgreSQL 16\n17 tables, TEXT PKs"]
end
subgraph "Agent (certctl-agent)"