Prerequisites

Before deploying EJBCA and SignServer to cloud environments, ensure the systems and tools described on this page are in place. Some prerequisites are required for any deployment, and others only apply to production environments or specific configurations.

Kubernetes and Tooling

Tool	Version	Notes
Kubernetes	1.32+	A functioning cluster with `kubectl` configured to reach it. Any CNCF-conformant distribution is supported, including AKS, EKS, GKE, and self-managed clusters.
kubectl	Matching your cluster version	Must be configured with a kubeconfig that has sufficient permissions to create namespaces, deployments, services, secrets, and ingress resources.
Helm	3+	Used to install and manage the SignServer Helm chart.
Ingress NGINX	-	Required if exposing SignServer outside the cluster using Ingress. After installing, enable controller snippets to allow client certificate authentication by setting `controller.allowSnippetAnnotations=true`. This setting is disabled by default from Ingress NGINX v1.9.0 onwards. Ingress NGINX is no longer recommended, and new deployments should use an actively maintained alternative, such as an NGINX reverse proxy

Certificate Authority

SignServer requires a PKI for two distinct purposes. Both can be served by the same CA, but it helps to understand the distinction:

Infrastructure certificates are used for:

The TLS certificate securing HTTPS access to SignServer
The CA certificate that SignServer uses to verify administrator client certificates when accessing the Admin Web

Signer certificates are the signing keys and certificates used by SignServer workers to perform signing operations: code signing, document signing, timestamping, and so on.

EJBCA is a production-grade open-source CA that can be deployed in the same Kubernetes cluster using the EJBCA Community Helm chart. If you are starting from scratch and do not yet have a CA, set up EJBCA first, then return here.

Issue a TLS Server Certificate with EJBCA: for the infrastructure TLS certificate
Issue a Client Authentication Certificate with EJBCA: for the administrator browser certificate required to access the Admin Web

Database

A database is required for any deployment where data needs to persist across pod restarts.

SignServer supports the following databases:

MariaDB (Recommended for most deployments)
MySQL
PostgreSQL
Oracle Database
Microsoft SQL Server
Azure SQL

Ephemeral H2 database: The Helm chart defaults to an in-memory H2 database that requires no external setup. This is suitable for quickly verifying a cluster setup, but data does not persist across pod restarts and it is not suitable for production use. For any real deployment, configure an external database before deploying.

If you need to run a database in the same cluster, the following Bitnami Helm charts are a convenient option: PostgreSQL · MariaDB. For connection configuration, see Connect SignServer to External Database.

Hardware Security Module (HSM)

An HSM is required for production deployments where signing keys must be stored and used in a tamper-resistant hardware boundary. SignServer supports two integration approaches depending on the HSM type:

PKCS#11 via sidecar container: For HSMs that expose a PKCS#11 interface. A separate sidecar container (p11proxy) runs alongside the SignServer container and handles communication with the HSM over the network. Supported HSMs:

HSM	Integration guide
SoftHSM2	SignServer SoftHSM2 integration in Kubernetes (For development and testing only, not for production use)
Thales Luna	SignServer Thales Luna Integration in Kubernetes
Utimaco uTrust / CryptoServer	SignServer Utimaco uTrust and CryptoServer Integration in Kubernetes
Entrust nShield Connect	SignServer Entrust nShield Connect Integration

REST API: For HSMs with a REST interface. The SignServer container connects directly to the HSM with no sidecar required.

Supported HSMs:

Microsoft Azure Key Vault
Microsoft Managed HSM
Fortanix Data Security Manager (DSM)

An HSM is not required to get started. You can deploy and explore SignServer using a software keystore (PKCS#12) or SoftHSM2 first, and add a production HSM later. HSM setup is typically done after the initial deployment once SignServer is running and accessible.

Container Registry Access

Community Edition images are hosted under keyfactor/signserver-ce and require no authentication.

Enterprise Edition images are hosted on the Keyfactor container registry and require an imagePullSecret configured in your cluster. Contact support@keyfactor.com if you do not have registry credentials.