An architectural overview covering intent, capabilities, and the road ahead.
I built TrustBox to solve a specific problem in the Enterprise PKI space: connecting powerful, raw cryptographic engines to modern orchestration environments efficiently and securely. This document provides a high-level overview of the architecture, its approach to certificate lifecycle management (CLM), and its focus on distributed, secure environments — all built entirely with open-source tools.
TrustBox is an Enterprise Certificate Lifecycle Management platform, fundamentally engineered around a single architectural truth: No system ever communicates directly to the cryptographic Certificate Authority (CA) engines.
By positioning an asynchronous API management layer strictly as a "Choke Point" intercepting external workflows (Intune, Kubernetes, REST clients), TrustBox becomes the singular enforcement zone for Policy, Compliance Logging, Inventorying, and Authentication.
cert-manager (Kubernetes)
SCEP (Intune/MDM)
REST Consumers
↓
[ TrustBox Secure Edge API ] ←—— [ WebAuthn / OIDC UI Clients ]
↓ ↓
[ Internal Core CA Engine ] [ Database Inventory ]
(Root/Intermediate CAs) (Lifecycles, Policy, RBAC)
(SSH Client/Host CAs) ↑
↓ [ Async Webhook Broker ]
[ Edge Network Proxy ] (Reconciliation Engines)
(CRL over HTTP, OCSP Routing)I found myself increasingly interested in the intersection where Identity, PKI, DevSecOps, Python, Kubernetes, mTLS, and open-source all collide. As I shopped commercial vendors to modernize an internal PKI and certificate lifecycle management environment, I grew frustrated with the cost of certificate issuance. I believe there is no valid reason issuing privately signed, trusted certificates should cost anything beyond the management platform itself—the industry-standard per-cert pricing models simply do not scale.
Instead of just complaining about it, I decided to build a solution. An open source "PKI in a Box" seemed immensely valuable for testing mTLS configurations, securing container deployments, and evaluating home lab architectures. I stopped writing minor scripts and focused on architecting a robust, production-capable platform that solved the issues I was encountering.
(As of Current Milestone)
The following capabilities have been fully implemented and are operational within the current TrustBox build:
Additionally, the underlying platform is uniquely performant out-of-the-box. Deploying standard local tests on developer workstations natively supports sustained asynchronous loads of 20 issuances per second (via --window and --rate stream profiles) continuously coordinating through Postgres, Redis loops, and OpenBao without failures or lag natively via docker-compose.
TrustBox guarantees strict privacy of internal operations by refusing to artificially generate private key materials. All clients integrate with TrustBox via pre-generated Certificate Signing Requests (CSRs). This explicitly solves Key Escrow concerns for sensitive endpoints while matching modern infrastructure norms.
TrustBox acknowledges that networks fail during issuance workloads. Signing actions are processed rapidly against the downstream cryptographic Core CAs and returned to consumers immediately, while heavy SQL database inventories or lifecycle events are decoupled via asynchronous message brokers (Redis/TaskIQ). If queues fail, TrustBox runs a background Reconciliation Engine matching raw Cryptographic records against internal SQL records automatically.
To avoid strict CA vendor-lock-in, the API routing isolates its core cryptographic requirements behind an abstract interface (CABackend ABCs). TrustBox acts cohesively regardless if the underlying Core Engine providing the certificates is OpenBao (HashiCorp Vault), Azure Key Vault, or Google Cloud CAS.
A crucial future architectural direction is tight integration with decoupled, stateless Edge Registration Authorities (RAs). TrustBox serves as the central control plane, distributing explicitly bounded issuance policies (via mTLS) to lightweight Edge RA nodes deployed deep inside remote data centers, branch offices, or factory floors. These nodes will validate local CSRs against Central Core policy and seamlessly request signatures over secure channels, ensuring true edge resilience without fragmenting the PKI root.
Rather than trusting bare configurations, TrustBox explicitly validates client connectivity:
X-Forwarded-For) are securely resolved using predefined Trusted Proxy Middleware loops, stopping IP spoofing immediately at the edge framework.TrustBox natively supports modern access controls:
TrustBox validates every incoming CSR structurally before allowing the CA engine to execute a signature. Edge rules validate SAN combinations, CN matching patterns, TTL thresholds, and matching OIDC authorization blocks, providing programmable validations over cryptographic identities.
By hosting protocol-specific adapters natively, TrustBox connects legacy and modern systems trivially into the singular issuance stream.
A. Kubernetes Integrations (cert-manager)
TrustBox exposes HMAC-signed secure webhook receivers directly consumable by standard Kubernetes clusters. Workloads spin up dynamically, and TrustBox inherently tracks every unique POD container requesting certificates without complex intermediate proxies.
B. SCEP / Intune Workflows
IoT configurations and Microsoft Intune devices communicate via SCEP into the internal adapter. TrustBox parses the Intune dynamic challenge payloads, authorizes the device via external API validations, and repackages signed responses accurately.
C. SSH Certificate Management
TrustBox extends beyond mere TLS/X.509 coverage into OpenSSH environments. SSH Hosts and Users request explicit, short-lived Certificates authorized mapped via the internal DB inventory solving the complexities of "orphaned authorized_keys" and key-rotation failures outright.
TrustBox enforces high security upon boot for bare-metal integrations. The system offers an auditable command line deployment process ensuring Root CAs and administrative credentials rely on cryptographic secrets initialization ceremonies mapped to:
Any internal cryptographic database secrets are fully AES-256-GCM encrypted prior to being stored, ensuring absolute zero-knowledge postures over downstream infrastructures.
While TrustBox currently comfortably supports aggressive traditional CI/CD scaling (like the 20 issuance / sec stress tests for VMs and Containers), my primary future scalability goal specifically targets Agentic AI and high-frequency tool-call identities.
As AI Agents execute granular operations across enterprise boundaries (running scripts, querying databases autonomously, or communicating across boundaries), they require hyper-short-lived, verifiable identities generated in milliseconds. Building out TrustBox's pipeline to explicitly test and benchmark Fortune-100 tier issuance velocities (thousands of isolated, policy-driven mTLS and SSH signatures an hour) for autonomous workloads is the immediate roadmap priority.