> ## Documentation Index
> Fetch the complete documentation index at: https://docs.certgovernance.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Closed-Loop Certificate Delivery

> CertForge doesn't just issue certificates — it completes the loop by delivering them to the endpoint. Three paths, every environment covered.

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](/guides/acme-setup)

***

### 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](/guides/certforge-issuer)

***

### 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](/guides/device-connector)

***

## 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.

```go theme={null}
// 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](https://github.com/CertForge-LLC/certforge-connector#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.