Certificates and keys
A Licensing Server signs every license it issues (how licensing works), so it is, at heart, a small certificate authority that you operate. This page explains how.
Minted at first boot
A fresh install mints its own hierarchy the first time it starts: a self-signed, long-lived root CA carrying your vendor id in its name, and a signing CA beneath it that does the day-to-day license signing and renews automatically. Everything is local; there is no external CA, no ACME, and no outbound requirement. An install migrated from the cloud service (a support-assisted procedure during the beta) adopts your existing deployment root as the top of the hierarchy instead, which is what keeps fielded products trusting the new server.
The passphrase
The CA private keys live in the appliance's PKI volume, encrypted at rest under
SWS_PKI_KEY_PASSPHRASE (in your install kit's sws.env; the generator minted or
accepted it at setup). The server refuses to boot with unencrypted CA keys unless
you explicitly configure otherwise. Keep the passphrase with your secrets manager;
you will need it on every host that runs the appliance, and at every
restore.
Your products' trusted root
Your applications embed this server's root certificate so the SDK can validate the
licenses it signs: download deployment-root.crt from this server's console, under
Settings → Deployment certificates, ship it in your product, and pass it to the
SDK via add_trusted_root / AddTrustedRoot. The same shipped product keeps
working across hostnames, and after migrating from the cloud service to this
server.
Key custody
The root key signs your licensing, and nobody else has a copy. That is the point of self-hosting, and its price.
- A database dump is not a backup. The PKI volume (the keys) must be part of
every backup; the built-in
sws-backupincludes it precisely so this cannot be forgotten. - Loss and leak are different disasters. A lost key is survivable: mint a new hierarchy and ship a product update embedding the new root. A leaked key lets someone forge licenses your products accept, the same threat model as a leaked code-signing key. Treat it accordingly, and cold-store it.