mirror of
https://github.com/shankar0123/certctl.git
synced 2026-06-07 15:01:32 +00:00
docs: add step-ca and OpenSSL CA to V2 roadmap, fix F5/IIS status
- Added step-ca and OpenSSL/Custom CA as planned V2 issuer connectors across README, architecture, connectors, and demo-advanced docs - Fixed F5 BIG-IP and IIS target status from "Implemented" to "Interface only" — both are stubs with mapped-out flows but no actual API calls yet - Updated all diagrams and tables to be consistent across docs - DNS-01, step-ca, OpenSSL, F5, IIS all listed under V2.0 roadmap Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
shankar0123
+11
-7
@@ -40,13 +40,15 @@ flowchart TB
|
||||
subgraph "Issuer Backends"
|
||||
CA1["Local CA\n(crypto/x509)"]
|
||||
CA2["ACME\n(Let's Encrypt)"]
|
||||
CA3["Vault PKI\n(future)"]
|
||||
CA3["step-ca\n(planned)"]
|
||||
CA4["OpenSSL / Custom CA\n(planned)"]
|
||||
CA5["Vault PKI\n(planned)"]
|
||||
end
|
||||
|
||||
subgraph "Target Systems"
|
||||
T1["NGINX\n(SSH + reload)"]
|
||||
T2["F5 BIG-IP\n(REST API)"]
|
||||
T3["IIS\n(WinRM)"]
|
||||
T1["NGINX\n(file write + reload)"]
|
||||
T2["F5 BIG-IP\n(iControl REST, planned)"]
|
||||
T3["IIS\n(WinRM, planned)"]
|
||||
end
|
||||
|
||||
DASH --> API
|
||||
@@ -345,15 +347,17 @@ flowchart TB
|
||||
II["IssuerConnector Interface\nIssueCertificate() | RenewCertificate()\nRevokeCertificate() | GetOrderStatus()"]
|
||||
II --> LC["Local CA"]
|
||||
II --> ACME["ACME v2"]
|
||||
II --> VP["Vault PKI (future)"]
|
||||
II --> SC["step-ca (planned)"]
|
||||
II --> OC["OpenSSL / Custom CA (planned)"]
|
||||
II --> VP["Vault PKI (planned)"]
|
||||
end
|
||||
|
||||
subgraph "Target Connectors"
|
||||
direction TB
|
||||
TI["TargetConnector Interface\nDeployCertificate()\nValidateDeployment()"]
|
||||
TI --> NG["NGINX"]
|
||||
TI --> F5["F5 BIG-IP"]
|
||||
TI --> IIS["IIS"]
|
||||
TI --> F5["F5 BIG-IP (interface only)"]
|
||||
TI --> IIS["IIS (interface only)"]
|
||||
end
|
||||
|
||||
subgraph "Notifier Connectors"
|
||||
|
||||
+17
-13
@@ -6,8 +6,8 @@ Connectors extend certctl to integrate with external systems for certificate iss
|
||||
|
||||
Three types of connectors:
|
||||
|
||||
1. **Issuer Connector** — Obtains certificates from CAs (ACME, Local CA, Vault, DigiCert)
|
||||
2. **Target Connector** — Deploys certificates to infrastructure (NGINX, F5, IIS)
|
||||
1. **Issuer Connector** — Obtains certificates from CAs (Local CA, ACME; step-ca, OpenSSL, Vault, DigiCert planned)
|
||||
2. **Target Connector** — Deploys certificates to infrastructure (NGINX implemented; F5, IIS interface only)
|
||||
3. **Notifier Connector** — Sends alerts about certificate events (Email, Webhooks, Slack)
|
||||
|
||||
All connectors accept JSON configuration at initialization, support config validation, and are registered in the service layer. Issuer connectors run on the control plane; target connectors run on agents.
|
||||
@@ -120,6 +120,15 @@ The connector is registered in the issuer registry under `iss-acme-staging` and
|
||||
|
||||
Location: `internal/connector/issuer/acme/acme.go`
|
||||
|
||||
### Planned Issuers (V2)
|
||||
|
||||
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.
|
||||
- **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.
|
||||
|
||||
### Building a Custom Issuer
|
||||
|
||||
Here's the structure for a HashiCorp Vault PKI issuer:
|
||||
@@ -270,31 +279,28 @@ The `reload_command` defaults to `systemctl reload nginx` but can be overridden
|
||||
|
||||
Location: `internal/connector/target/nginx/nginx.go`
|
||||
|
||||
### Built-in: F5 BIG-IP
|
||||
### Planned: F5 BIG-IP (Interface Only)
|
||||
|
||||
Deploys certificates to F5 BIG-IP load balancers via the iControl REST API. This is the standard integration path for organizations using F5 for TLS offloading. The connector uploads the certificate and private key to the F5 SSL certificate store, then updates the SSL profile on the virtual server to reference the new certificate.
|
||||
The F5 BIG-IP target connector interface is built with the iControl REST flow mapped out, but the actual API calls are not yet implemented. The planned flow is: authenticate via `POST /mgmt/shared/authn/login`, upload cert PEM via `POST /mgmt/tm/ltm/certificate`, update the SSL profile via `PATCH /mgmt/tm/ltm/profile/client-ssl/{profile}`, and validate deployment by checking profile status. Implementation is planned for V2.
|
||||
|
||||
Configuration:
|
||||
Configuration (defined, not yet functional):
|
||||
```json
|
||||
{
|
||||
"host": "f5.internal.example.com",
|
||||
"username": "admin",
|
||||
"password": "...",
|
||||
"partition": "Common",
|
||||
"virtual_server": "/Common/vs_api",
|
||||
"ssl_profile": "/Common/clientssl_api"
|
||||
}
|
||||
```
|
||||
|
||||
The connector authenticates to the F5 REST API at `https://{host}/mgmt/tm/`, uploads the certificate via `POST /mgmt/tm/sys/crypto/cert`, uploads the key via `POST /mgmt/tm/sys/crypto/key`, and binds them to the specified SSL profile. The F5's native REST API handles certificate chain assembly. Agent credentials for the F5 API are stored locally on the agent, never on the control plane.
|
||||
|
||||
Location: `internal/connector/target/f5/f5.go`
|
||||
|
||||
### Built-in: IIS
|
||||
### Planned: IIS (Interface Only)
|
||||
|
||||
Deploys certificates to Microsoft IIS web servers via WinRM (Windows Remote Management). This connector is for organizations running Windows-based infrastructure where IIS terminates TLS. The connector executes PowerShell commands over WinRM to import a PFX certificate into the Windows certificate store and bind it to an IIS site.
|
||||
The IIS target connector interface is built with the WinRM/PowerShell flow mapped out, but the actual remote execution is not yet implemented. The planned flow is: transfer a PFX bundle to the Windows server via WinRM, run `Import-PfxCertificate` to install it into the certificate store, and run `Set-WebBinding` to bind the certificate to the IIS site. Implementation is planned for V2.
|
||||
|
||||
Configuration:
|
||||
Configuration (defined, not yet functional):
|
||||
```json
|
||||
{
|
||||
"host": "iis-server.internal.example.com",
|
||||
@@ -306,8 +312,6 @@ Configuration:
|
||||
}
|
||||
```
|
||||
|
||||
The deployment flow: the connector combines the certificate and private key into a PFX (PKCS#12) bundle, transfers it to the Windows server via WinRM, runs `Import-PfxCertificate` to install it into the specified certificate store (typically `WebHosting` or `My`), then runs `Set-WebBinding` to bind the new certificate to the IIS site. Old certificate bindings are updated in-place so there is no downtime window.
|
||||
|
||||
Location: `internal/connector/target/iis/iis.go`
|
||||
|
||||
## Notifier Connector
|
||||
|
||||
@@ -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 internal PKI (Vault, ADCS), some use commercial CAs (DigiCert, Sectigo). The connector interface means certctl doesn't care — it calls `IssueCertificate()` and gets back a signed cert regardless of the backend.
|
||||
**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.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
@@ -129,8 +129,10 @@ flowchart TD
|
||||
|
||||
A --> E["Local CA\n(crypto/x509)"]
|
||||
A --> F["ACME\n(Let's Encrypt)"]
|
||||
A --> G["Vault PKI\n(future)"]
|
||||
A --> H["DigiCert API\n(future)"]
|
||||
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)"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user