Skip to main content

​
Certificate Lifecycle

Every certificate that CertForge manages passes through the same pipeline, regardless of how it was requested. Understanding this flow makes it easier to configure Trust Profiles, troubleshoot rejections, and design your PKI strategy.

​
End-to-end flow

​
Request protocols

All four entry points converge at the same policy and governance layer. What differs is how the request arrives and where the certificate ends up.

ACME Client

Spec: RFC 8555 — standard ACME protocolCommon use: cert-manager (Kubernetes), Certbot, any ACME clientAuth: ACME account key; directory at /acme/directoryCSR: Generated by the client — CertForge validates the domain against a Trust ProfileDelivery: ACME finalize response; cert-manager stores automatically in a Kubernetes Secret

Enrollment API

Spec: CertForge REST API — POST /v1/enrollCommon use: CI/CD pipelines, scripts, internal toolingAuth: API key (Bearer token) or mTLS client certificateCSR: Provided by the caller in the request body (PEM)Delivery: Certificate returned in the JSON response body; caller stores it

Dashboard

Spec: CertForge web UI — Issuance → EnrollCommon use: One-off certificates, testing, manually managed servicesAuth: CertForge user login (SSO or local)CSR: Paste an existing CSR or generate one via the wizardDelivery: Downloadable PEM in the browser; tracked in Inventory

Device Connector

Spec: CertForge connector agent — polls the API every 30 secondsCommon use: AudioCodes SBC, F5 BIG-IP, network appliancesAuth: Connector API key (per deployment)CSR: Device generates its own CSR, or the connector generates a key + CSR externally when ACME DNS SANs are requiredDNS challenge: Handled server-side — manual confirmation in the dashboard or automated via a DNS providerDelivery: Connector installs the private key, leaf cert, and intermediate chain directly onto the device via its management API

​
Governance

Every request — regardless of source — is evaluated by the Trust Profile’s governance rules before a certificate is issued. See Approvals for escalation timers, peer approval requirements, and audit details.

​
Certificate Authorities

CertForge supports three types of CA. The Trust Profile determines which one signs each certificate.

​
ACME CA (ZeroSSL, Let’s Encrypt, DigiCert)

CertForge acts as an ACME client and obtains publicly-trusted certificates on your behalf using DNS-01 challenge validation. DNS challenge modes: Configure DNS providers in Admin → DNS Accounts. Rate limits (Let’s Encrypt):
  • 50 certificates per registered domain per week
  • 5 duplicate certificates per week
CertForge tracks issued certificates and will warn before you hit a rate limit.

​
Internal CA

CertForge signs the certificate directly using a CA keypair stored in the platform. No external calls. Issuance is instant. Root CA — self-signed; best for private PKI entirely under your control. Distribute the root certificate to all machines that need to trust it. Intermediate CA — signed by another CA (internal or external). Keeps your root CA offline. Create one by generating a CSR in CertForge and uploading the signed certificate. Key storage: Private keys are encrypted at rest with AES-256-GCM. In multi-node deployments the encrypted keys live in the database and are decrypted in memory when needed. The encryption key is set via CERTFORGE_STORAGE_KEY — keep this secret.

​
Private Connector CA

The connector agent running on-premises signs CSRs using a locally held CA keypair (or HashiCorp Vault PKI). The private key never leaves the on-prem environment. CertForge audits and records the issuance; the signed certificate is returned through the connector API. Use for: air-gapped networks, regulated environments, or any scenario where private keys must not leave your infrastructure.

​
Choosing a CA type

​
Certificate chain

CertForge always delivers the full chain: the leaf certificate plus any intermediate CA certificates. Serving only the leaf cert causes browser “Not secure” warnings even when the leaf itself is valid — the client cannot build a trust path to the root. For device connector installations, the connector pushes the leaf cert and the chain separately so the device can serve them correctly during TLS handshakes.

​
Auto-renewal

Certificates issued by CertForge are automatically renewed before expiry. The renewal window is set per Issuance Profile (Renew Before Expiry, in days). If not set, CertForge defaults to 30 days, capped at ⅓ of the certificate’s validity period. Auto-renewal can be disabled per certificate in Inventory (useful for certs that are intentionally short-lived or managed externally). Discovered certificates — from CT Log scans, TLS scans, or CA Connector sync — are monitored for expiry but are not renewed by CertForge.

​
Revocation

CertForge supports CRL (Certificate Revocation List) distribution for internal CAs. The CRL endpoint is available at /crl/{ca-id}/crl.pem. Revoked certificates are excluded from inventory counts and flagged in compliance reports.