Closed-Loop Certificate Delivery

Most certificate platforms stop at issuance. CertForge completes the full lifecycle: discover → govern → issue → deliver to the endpoint — automatically, without a separate deployment step. This is what closed-loop means: a certificate is not done until it is installed on the device or service that needs it.

Three delivery paths

CertForge closes the loop through three complementary paths. Most organizations use all three.

1. ACME clients — servers and applications

Any endpoint running a standard ACME client gets the full loop natively: the client requests the cert, CertForge issues it under your policy, and the client installs it and reloads the service — automatically, without any additional tooling. Works out of the box with certbot, acme.sh, Caddy, Traefik, nginx-proxy, HAProxy, and any RFC 8555-compatible client.

[ACME client on server] ──── ACME protocol ──→ [CertForge] ──→ signed cert
        │
        └── installs cert + reloads service automatically

CertForge’s ACME endpoint is a drop-in replacement for Let’s Encrypt. Clients require no reconfiguration — only the ACME directory URL changes. Every issuance, renewal, and revocation is governed by your Domain Trust Profile and recorded in the audit trail. → ACME setup guide

2. cert-manager — Kubernetes workloads

For Kubernetes, CertForge ships a native cert-manager external issuer (certforge-issuer). Install it into your cluster and any cert-manager Certificate manifest is automatically routed through CertForge policy — no changes to your existing manifests required. cert-manager handles the full Kubernetes loop: requests the cert from CertForge, stores it as a Kubernetes Secret, rotates it before expiry, and makes it available to your pods.

[cert-manager] ──── CertificateRequest ──→ [certforge-issuer] ──→ [CertForge]
       │                                                                  │
       └── stores cert in Secret ←───────────────────────── signed cert ─┘

→ certforge-issuer guide

3. certforge-connector — network devices and private infrastructure

For network devices, SBCs, load balancers, and any endpoint on a private management VLAN — devices that can’t run an ACME client — CertForge closes the loop through the open-source certforge-connector agent. The connector runs inside your network (no inbound firewall rules needed), polls CertForge for pending renewal jobs, pulls the CSR from the device, gets it signed under your Domain Trust Profile, and installs the certificate back on the device.

[CertForge] ←── poll (outbound only) ── [certforge-connector]
                                                    │
                                         reaches private VLAN
                                                    │
                                    [network device — F5 / Ribbon / AudioCodes / ...]
                                            pull CSR ↑  ↓ install cert

Currently supported out of the box:

Device	Driver
F5 BIG-IP (iControl REST, TMOS 11.6+)	`f5`
Ribbon SWe-Lite SBC	`ribbon`
AudioCodes Mediant (VE/E/SW/HW)	`audiocodes`

→ Connector setup guide

Add any device — no vendor ticket required

This is the key architectural difference from closed-loop solutions that maintain a fixed integration catalog. The connector is open source. Adding support for a new device type means implementing a single Go interface — the same interface used by the built-in F5, Ribbon, and AudioCodes drivers. A new driver is typically a weekend project, not a multi-month vendor engagement.

// The entire interface a device driver implements:
type Device interface {
    Connect(ctx context.Context, host string, port int, creds Credentials) error
    GetCSR(ctx context.Context) ([]byte, error)
    InstallCert(ctx context.Context, certPEM, keyPEM, chainPEM []byte) error
    Close() error
}

Once implemented, register it with the connector — no CertForge update required. The device type appears automatically in the CertForge UI as soon as the connector starts reporting it. This means:

Your team controls the integration timeline — not a vendor’s roadmap
No professional services engagement to add a device the vendor doesn’t support yet
Drivers live in your codebase — version-controlled, auditable, owned by you
Contribute upstream — submit drivers back to the open-source repo for the community

→ Adding a device type on GitHub

Which path should I use?

Environment	Recommended path
Linux / macOS servers running Caddy, Traefik, nginx, HAProxy	ACME client (native)
Any server where you can install certbot or acme.sh	ACME client
Kubernetes clusters	cert-manager + certforge-issuer
F5 BIG-IP, Ribbon SBC, AudioCodes	certforge-connector
Any other network device or appliance	certforge-connector with custom driver
CI/CD pipeline or custom application	REST API

Most organizations use all three paths across their infrastructure — ACME for servers, cert-manager for Kubernetes, and the connector for network/telecom devices — with a single CertForge instance governing all of them under consistent Domain Trust Profiles.

Governance across all paths

Regardless of which delivery path issues a certificate, every cert:

Must be authorized by a Domain Trust Profile before issuance
Goes through the configured approval workflow (if required by the DTP)
Is recorded in the audit trail with full chain of custody
Appears in the certificate inventory and dashboard
Triggers alerts when approaching expiry
Is covered by scheduled reports

The delivery mechanism is invisible to governance — policy is enforced consistently whether the requestor is a certbot client, a cert-manager controller, or a connector agent.

​Three delivery paths

​1. ACME clients — servers and applications

​2. cert-manager — Kubernetes workloads

​3. certforge-connector — network devices and private infrastructure

​Add any device — no vendor ticket required

​Which path should I use?

​Governance across all paths