How sslbrain Works

Architecture, security, and data flow.

sslbrain Cloud and your sslbrain

Two distinct systems. Your data stays with you.

cloud.sslbrain.com

License validation
Vault KEK storage
Signed agent packages
ACME server for paid CAs

Your sslbrain

Runs locally on your network
SQLite database, all data local
HTTPS only outbound
Cloud cannot connect to your sslbrain

sslbrain and your servers

Two deployment models. No inbound ports required on targets.

Push

sslbrain connects to your servers and deploys certificates directly.

Linux: SSH
Windows: WinRM

Pull

The Windows Service Agent fetches tasks from sslbrain via mTLS-authenticated HTTPS.

No inbound ports on targets
Agent polls sslbrain for signed, encrypted task packages
mTLS with ECDSA P-384 client certificate

This agent-based approach means sslbrain handles any platform with a certificate — Windows, Linux, macOS, or network appliances — through the same orchestration layer. No platform-specific licensing, no separate tools.

Certificate sources

We support any ACME-based CA including:

Free CAs

Let's Encrypt
Google Trust Services

Paid CAs

DigiCert
GlobalSign Atlas
Sectigo

Own CA

Internal CA
Custom CA

ACME Cloud certificate flow

Your sslbrain sends the request. ACME Cloud handles the rest.

ACME Cloud auto-selects the cheapest available CA
Automatic failover between CAs
Free CAs connect directly, paid CAs go via unit licenses

Vault and encryption

A database copy is useless without access to your Cloud Vault.

3-layer encrypted vault

All local data including private keys and login credentials is encrypted with XChaCha20-Poly1305 and a 256-bit key via libsodium. Encryption keys are wrapped on the appliance with the master key. The master key never leaves the appliance. sslbrain Cloud Vault (OpenBao, EU-hosted) holds only the KEK that wraps the master key on disk; the KEK lives only in memory at boot and is discarded after unwrap.

Every time sslbrain starts, it contacts sslbrain Cloud with a rotating API key and rotating encryption key. A copy of the database is therefore useless without access to your Cloud Vault.

By default, Cloud Vault blocks access attempts from a new IP or with an old API token. You can allow it through your account or settings.

This effectively protects against data access by copying files or server images. The server must of course still be protected locally.

sslbrain Cloud Vault (AWS) KEK (rotating) Master Key private keys, credentials Rotating API key + IP check Your sslbrain (local) XChaCha20-Poly1305, 256-bit

Agent execution and mTLS

Secure execution from orchestrator to server. No secrets in files, no scripts on disk.

Stdin execution

Scripts are piped directly to the interpreter via stdin. No temporary script files are written to disk. Secrets are passed as environment variables, not command-line arguments.

Bash: echo "$script" | bash -s
Python: echo "$script" | python3 -
PowerShell: in-process via PowerShell.Create()
Read-only container, no-new-privileges

mTLS and encrypted packages

The Windows Service Agent enrolls with an ECDSA P-384 client certificate at registration. sslbrain's internal CA issues the certificate. All communication uses mutual TLS authentication.

Automatic certificate enrollment at registration
Automatic renewal before expiry (90 days)
ECIES-encrypted task packages (ECDH + AES-256-GCM)
Bearer token fallback for backward compatibility

Agent signing

Every script that runs on your servers is signed. No exceptions.

YubiKey-signed agents

All scripts are signed by FairSSL with ECDSA P-384 via YubiKey. Per-file signatures. Community scripts are reviewed and signed by FairSSL. The Windows Service Agent only runs signed files.

ECDSA P-384 signature per file (not per package)
Physical YubiKey touch per signing
Category (read/write) baked into signature
Date baked into signature (no backdating)
Developer Code review YubiKey sslbrain Cloud Your sslbrain Server

ScriptPolicy + Group Policy

Every server has a ScriptPolicy defining what it accepts. Restrict to FairSSL-signed scripts only, allow community scripts, or allow everything including custom scripts. Lockable via Group Policy.

FairSSL agents: Written and signed by FairSSL. Maintained and tested.
Community agents: Written by users, reviewed and signed by FairSSL. If we sign it, we reviewed it.
Custom agents: Written by you. Sign with your own key or run unsigned. FairSSL never signs code we have not reviewed.
TrustSignedBefore: Set a date. The agent rejects anything signed after that date until you approve. Full control over updates.

Supported platforms

From Windows to Linux to network appliances.

Windows

IIS Exchange ADFS RDP SQL Server

Linux

Apache Nginx HAProxy Tomcat

Network

FortiGate FortiMail NetScaler

Custom

YAML agents Any platform via scripting

Protocols

Standards-based from top to bottom.

Certificate issuance

ACME v2 (RFC 8555)
ARI Draft v4

Validation

DNS-01
HTTP-01
TLS-ALPN-01

Deployment

SSH
WinRM
REST
Windows Service Agent

Scripting

Bash
PowerShell
Python

Code transparency

Everything is inspectable. No black boxes.

sslbrain core

sslbrain is PHP source-available. You can read every line of code running on your server.

All scripts readable in UI
Network audit shows all outbound connections
All code visible and inspectable on every plan

Agents and tools

Agents are YAML + scripts on GitHub. The Windows Service Agent is .NET and verifies signatures. sslbrain handles the ACME protocol against the CA so your servers never talk to a CA themselves.

YAML agent definitions on GitHub
Windows Service Agent verifies ECDSA P-384 signatures
ACME-to-CA traffic handled by sslbrain so servers never talk to a CA themselves

Enterprise Security Guarantees

Three architectural commitments that set sslbrain apart.

No-Takeover Architecture

sslbrain cannot push code to your servers. Agents run locally on your infrastructure, initiated by your admin. There is no remote execution path from our cloud to your endpoints. This eliminates SolarWinds-type supply chain risk by design.

Audit-Ready Source

sslbrain is source-available. Your security team can read every Python, Bash, and PowerShell script before it runs on your servers. No blind trust in compiled binaries. Every agent action is inspectable, auditable, and verifiable.

Hardware-Rooted Trust

Every agent is signed with ECDSA P-384 using a YubiKey hardware security key. The private signing key never leaves the physical device. Signatures are verified on every execution. Tampered or unsigned scripts are rejected before they run.