Security
sslbrain handles private keys and certificates, the most sensitive assets in your infrastructure. Here is how we protect them.
Vault
All private keys and sensitive data are stored in sslbrain's vault. The vault uses 3-layer encryption:
Layer 1: KMS
A key from sslbrain Cloud (or your own HSM) protects the next layer.
Layer 2: KEK
Key Encryption Key, encrypts the master key.
Layer 3: Master Key
Encrypts the actual data with XSalsa20-Poly1305 (strong, modern encryption with integrity protection).
Important: No single component can decrypt your keys alone. Even if someone copies the entire sslbrain database, the data is useless without the KEK and KMS key.
Vault unsealing
The vault must be unsealed at startup, otherwise sslbrain cannot access private keys. There are three methods:
| Method | Security | Recommended for |
|---|---|---|
| Auto-unseal (file) | Good | Most installations |
| Manual password | High | Environments with high security requirements |
| HSM / YubiKey | Highest | Enterprise installations |
Auto-unseal (recommended)
Stores the unseal key encrypted on disk. The vault opens automatically when sslbrain starts. It is the right balance between security and operational stability for most.
Manual unsealing
Requires an administrator to enter the password in the web interface after each restart. More secure, but sslbrain cannot renew certificates automatically while the vault is sealed.
HSM / YubiKey (Enterprise)
Uses a hardware security module for unsealing. The key never leaves the hardware.
KEK Rotation
Each time sslbrain starts, it fetches a new KEK from sslbrain Cloud. The old KEK is deleted from memory. Data is re-encrypted with the new KEK in the background.
Tip: This means that even if an attacker obtains an old KEK, it cannot be used to decrypt current data.
IP Protection
sslbrain Cloud knows your installation's IP address. If a request comes from a new IP or with an expired token, it is blocked.
Duplicate attempts, e.g. if someone restores a backup and tries to register with the same credentials, are detected and flagged automatically. The original installation is alerted.
Roles (RBAC)
sslbrain has three roles:
| Role | Permissions |
|---|---|
| Admin | Full control. Can create users, change settings, delete data. |
| Operator | Can issue and deploy certificates, manage servers. Cannot change users or security settings. |
| Viewer | Read-only access. Can view certificates, servers and logs. Cannot change anything. |
Roles are assigned per user. Local users are created in sslbrain. With LDAP/AD integration (Pro+), you can map AD groups to sslbrain roles.
Audit Log
Every action in sslbrain is logged in the audit log:
| Field | Description |
|---|---|
| Who | User or system |
| What | Action, e.g. "certificate issued", "server added", "user created" |
| When | Timestamp |
| Details | Affected resource, parameters |
Important: The audit log cannot be deleted or edited from the web interface. It is append-only.
Export the log to CSV or JSON via Settings > Audit log > Export for use in external SIEM systems or compliance reports.
Network
sslbrain is designed for minimal network exposure:
Inbound
Only 1 port (HTTPS, default 8443). Used by administrators accessing the web interface and by Windows Agents checking in.
Outbound
Only to fixed IP addresses (sslbrain Cloud) plus the CAs you use.
Tip: No inbound access from the internet is required. sslbrain does not need to be publicly exposed. Agents and administrators access it on the internal network.
For Enterprise installations, outbound connections can be disabled entirely (offline mode). See Settings.
Our pledge
No key storage
Private keys are generated and stored exclusively in your sslbrain installation. sslbrain Cloud never sees them.
No backdoors
There is no hidden access, no master key we can use, no remote shell.
No key escrow
We have no copy of your keys, and we cannot recover them.
Important: If you lose your vault password and backup key, your private keys are lost. We cannot help recover them. This is by design.