KeyNanny

Encrypted credential storage – All access data is persistently stored encrypted using CMS/PKCS#7 (AES-256). The encrypted files are not sensitive and can also be stored world-readable; the protection lies in the key, not the file.

Unix socket-based access – KeyNanny communicates exclusively via Unix Domain Sockets. Access is controlled via Unix file permissions – without additional network exposure. Each KeyNanny instance runs as the same Unix user as the accessing application.

Multi-instance architecture – Any number of parallel KeyNanny daemon processes (keynannyd) can be operated – one instance per application or namespace, with its own socket, its own user and its own set of credentials.

HSM integration via PKCS#11 – The encryption keys used by KeyNanny can be held in hardware security modules (HSMs).

Configuration file templating – Applications that require plain-text configuration files are provided via a template mechanism: on startup, a configuration with placeholders is rendered against KeyNanny values and written to a tmpfs directory. The application reads a complete, normal configuration – without ever leaving a password in the file system.

Secure credential transmission – Via an optional, easy-to-set-up web interface, passwords can be securely exchanged between administrators of different operator groups: the values are transmitted directly encrypted with the KeyNanny certificate, without ever passing over the network in plain text.

Automatic key rollover – Any number of generations of encryption certificates can be configured. KeyNanny automatically selects the currently valid encryption certificate for newly encrypted data; old data remains readable. A rekeying mechanism for all data facilitates cleanup when required.

Native OpenXPKI integration – Via the KeyNanny connector, credentials are integrated directly into OpenXPKI configurations. Database passwords, LDAP credentials and other secrets are read from KeyNanny without appearing in plain text in the OpenXPKI configuration.

Separation of responsibilities – Developers, service operators and operations administrators have clearly separated roles: developers maintain configuration templates without knowledge of production passwords; service operators can set service passwords without operations administrators being able to read them.

PKI infrastructure (OpenXPKI) – KeyNanny is the recommended credential store for OpenXPKI Enterprise Edition. Database passwords, LDAP bind credentials and other access data are sourced from KeyNanny. Integration is via the native KeyNanny::Connector without changes to the OpenXPKI application itself. Combined with an HSM, the encryption keys are modularly protected.

Web server key protection – Private keys for TLS certificates of web servers (e.g. Apache) no longer need to be available in plain text at startup. KeyNanny delivers the key passphrase directly to Apache via the SSLPassPhraseDialog mechanism – the private key is then only held with HSM protection.

Database credentials – Technical database users and their passwords are stored encrypted in KeyNanny. A password change requires no modification of configuration files or deployments.

Development and CI/CD – Configuration templates with KeyNanny placeholders can be safely versioned in Git repositories. Production passwords are never in the repository; the separation between configuration structure and sensitive values is structurally enforced.

Multi-team environments – In environments with separate operator groups (e.g. development, operations, security), KeyNanny enables the secure handover of credentials: an administrator of one group encrypts the value with the KeyNanny certificate of the target environment; the receiving administrator imports it without ever seeing the plain text.