How sslbrain Works
Architecture, security, and data flow.
The sslbrain Cloud (EU) service and your sslbrain
Two distinct systems. Your data stays with you.
cloud.sslbrain.com
Your sslbrain
- Private keys are generated on sslbrain On-Premise and stay there, together with the credentials for your servers and devices.
- On-Premise talks only to sslbrain Cloud (EU), outbound on port 443. The company behind Cloud and its hosting are in the EU.
- Messages to service agents through Cloud are end-to-end encrypted (E2E): Cloud passes them on but cannot read them.
- Cloud handles sign-in, email alerts, the licence and the public certificates. Keys to your DNS API stay with you unless you choose to keep them in Cloud.
Which data goes where
Your data stays on the appliance and is shown only in the local control panel, with local access. Cloud cannot fetch or see it.
Only what you use is sent out of the appliance: data about publicly issued certificates, sign-in to Cloud, data for the Cloud ACME server and client, and the server and certificate data you choose to include in email alerts.
Anonymous metadata is sent to Cloud when you issue certificates and use the DNS-API proxy.
If you choose to, you can let Cloud receive selected diagnostic data, send server information in alert emails, and receive logs for troubleshooting and for improving the product and the integrations.
DNS-API credentials can stay on your network. The appliance calls the DNS provider directly or through our proxy with TLS all the way to the DNS provider, so Cloud cannot read them. If you want to use ACME clients directly against Cloud, you can choose to store them in Cloud.
The appliance's vault encrypts with XChaCha20-Poly1305 and a 256-bit key. Messages between the appliance and the service agents are signed and encrypted with AES-256-GCM, both directly and through Cloud, which cannot read them.
sslbrain and your servers
Two deployment models. No inbound ports required on targets.
Push installation
The appliance connects to network devices and cloud services and deploys certificates directly.
Locally via service agent
The service agent fetches its tasks from sslbrain over HTTPS. Every message is signed and encrypted.
- Push installation: equipment that cannot run an agent, such as FortiGate, F5, pfSense, NetScaler and Palo Alto, gets the certificate from sslbrain On-Premise. It logs in through the device’s API (usually port 443) or over SSH (port 22) and installs it. Nothing is installed on the device.
- Windows and Linux servers get a service agent. It installs the certificate on its own server: IIS, Exchange, RDP and SQL Server on Windows, nginx, Apache and Postfix on Linux.
- From Professional, a service agent can also push to other servers and devices in its network, such as an HAProxy.
- Cloud services such as AWS, Azure and Cloudflare get the certificate from On-Premise through their API.
- On-Premise stores logins only for equipment without an agent, encrypted in its vault. Every delivery is checked, and if it fails, the certificate that was there before can be rolled back.
This approach with integrations 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.
Many sites, one appliance
Servers at a branch office, in a DMZ or at a hosting provider get a service agent that goes through sslbrain Cloud. No VPN is needed, and no ports are opened inbound.
- The sslbrain On-Premise installation sits in the head office. Each of the other networks, such as a remote site, a DMZ, a data centre or a customer network, gets one service agent.
- Each network connects only outbound on port 443, through its own firewall, to sslbrain Cloud (EU). There are no connections between the networks.
- A service agent connects to On-Premise via sslbrain Cloud (EU), E2E: Cloud passes the messages on and cannot read them.
- The service agent installs certificates on its own server and pushes them to the equipment in its network, such as a SonicWall, F5, FortiGate or NetScaler.
- No VPN and no inbound ports. One service agent per network is enough.
One appliance, many customer networks
If you run IT for several customers, one appliance in your own network can serve them all. Each customer network, a DMZ included, gets its own service agent and connects only outbound to sslbrain Cloud.
- One sslbrain On-Premise in your own network serves many customer networks. The private keys are generated there, not in sslbrain Cloud (EU).
- Each customer network gets a service agent. A customer’s DMZ is a network of its own with its own service agent.
- Each network connects only outbound on port 443, through its own firewall, to Cloud. The service agents connect via sslbrain Cloud (EU), E2E. There are no connections between customers.
- The service agent pushes certificates to the equipment in its own network, such as FortiGate, F5, SonicWall or a Windows server.
- No VPN to the customers and no inbound ports.
Certificate sources
We support any ACME-based CA including:
Free CAs
Paid CAs
Own CA
ACME Cloud certificate flow
Your sslbrain sends the request. ACME Cloud handles the rest.
- On your network, sslbrain On-Premise generates the private key. It is never seen by sslbrain Cloud (EU).
- On-Premise sends the certificate request (CSR) to Cloud, outbound HTTPS on port 443. In this flow On-Premise talks only to Cloud.
- Cloud proves the domain is yours, the way you choose: a CNAME delegation to your.autodns.sslbrain.net, access to your DNS provider’s API, or a dns-persist-01 TXT record. Any one of them is enough.
- The CA issues the certificate: Let’s Encrypt, DigiCert, Google Public CA, Sectigo or GlobalSign. Cloud follows a priority list and moves on to the next CA if one fails.
- The public certificate comes back to On-Premise over the same outbound connection.
- On-Premise delivers it where it is used: service agents on Windows and Linux servers (IIS, Exchange, nginx, Apache) install it, and On-Premise pushes it to F5, FortiGate, NetScaler, Palo Alto and other equipment.
Vault and encryption
All local data is encrypted. Cloud holds only an unlock key, not your data.
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. A dedicated vault operated by FairSSL 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 fetches the KEK from sslbrain Cloud with the appliance's own credentials, and the KEK is rotated at every start. A copy of the database is therefore useless without the appliance's own access to sslbrain Cloud.
Cloud hands the KEK only to the appliance's own credentials. A copied appliance is detected and locked until the account owner confirms it; the 12 backup words open the vault without Cloud.
This effectively protects against data access by copying files or server images. The server must of course still be protected locally.
Service agent execution and encryption
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.
echo "$script" | bash -s echo "$script" | python3 - PowerShell.Create() Own keys and encrypted messages
The install code is used only for the first enrolment. After that each service agent has its own key pair, and every message is signed and encrypted with AES-256-GCM, both directly and through Cloud, which cannot read them.
Integration signing
Every script that runs on your servers is signed. No exceptions.
- The appliance image and the integrations are signed with a hardware key (YubiKey). Service agents come from a signed catalogue, and the Windows files carry an Authenticode signature.
- With sslbrain On-Premise, only signed code is installed. Updates come automatically, or you approve them manually.
- Service agents check the signature before anything runs and run only signed scripts; the parameters are filtered against injection.
- The source can be read: every script can be read before it runs on your servers.
- A cloned appliance must be approved before it runs.
YubiKey-signed integrations
Every catalogue script is signed by FairSSL with ECDSA P-384 via YubiKey. Per-file signatures. A suggestion from a user is reviewed, locked and released by FairSSL under FairSSL's signature. The Windows service agent only runs signed files.
ScriptPolicy + Group Policy
Every server has a ScriptPolicy defining what it accepts. By default the service agents run only integrations and scripts signed with FairSSL's hardware key. Your own integrations run only where you switch them on. The policy is set on the server and can be locked via Group Policy; the appliance cannot change it.
Supported platforms
From Windows to Linux to network appliances.
Windows
Linux
Network
Custom
Protocols
Standards-based from top to bottom.
Certificate issuance
Validation
_dnsauth for a whole domain Deployment
Scripting
Code transparency
Everything is inspectable. No black boxes.
The core of sslbrain
The PHP source code for sslbrain is available for inspection. You can read every line of code running on your server.
Integrations and tools
Integration code is YAML and scripts, available with a free account under Source code in sslbrain Cloud. It is covered by the FairSSL Proprietary Source-Visible License v1. The Windows service agent is .NET and verifies signatures. The appliance handles the ACME protocol against the CA so your servers never talk to a CA themselves.
A free account lets you read the appliance, service agent and integration code under Source code in sslbrain Cloud. It is provided under the FairSSL Proprietary Source-Visible License v1, a proprietary licence.
If something is compromised
What an attacker can and cannot do in each part of the system.
sslbrain Cloud
Can stop an appliance, which is the lock against cloning, and refuse a licence. Cannot see the data on the appliance, control the appliance, send tasks to your servers or install anything. Updates need FairSSL's YubiKey signature, and you can choose manual updates.
The appliance
Can ask the service agents already installed to run FairSSL-signed integrations with input the attacker chooses. A package can only do what it was made for: certificates, bindings and restarting the service that belongs to them. Cannot publish updates or new FairSSL integrations. Your own integrations run only where you have switched them on at the server. The push credentials in the appliance's vault can be used by the attacker.
A service agent
Gives access only to the server it is on. Its key cannot be used for other servers, and the appliance can block it.
Enterprise Security Guarantees
Three architectural commitments that set sslbrain apart.
No-Takeover Architecture
The sslbrain Cloud service cannot send tasks to your servers or install anything on them. Your servers run only code FairSSL has signed on a hardware key, and your own integrations where you have allowed them. A compromised appliance can still direct your service agents to run FairSSL-signed scripts with attacker-chosen inputs, including installing an attacker-supplied certificate, and only ever at the privilege you granted the service agent. What it cannot do is introduce new or unsigned code.
Audit-Ready Source
The source code for sslbrain is available for inspection. Your security team can read every Python, Bash, and PowerShell script before it runs on your servers. The compiled Windows service agent is signed twice: Authenticode on the MSI, and a release manifest signed on FairSSL's YubiKey that pins the MSI's hash. You can also build it yourself from the source code.
Hardware-Rooted Trust
Every integration 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.
Get started
Download sslbrain and manage your certificates in minutes.