SignServer Community Edition on Ubuntu 24.04 on Azure User Guide

Overview

This image runs SignServer Community Edition 7.3.2, the open source server-side digital-signature application from Keyfactor, on Ubuntu 24.04 LTS. SignServer keeps your signing keys on the server: applications call it over HTTP and REST and it performs the signing centrally, so private keys never have to be distributed to laptops or build machines. Signing operations are configured as workers - a PDF signer, an XML signer, a generic CMS or plain data signer, and an RFC 3161 time stamp authority for trusted timestamping - each with its own key and access rules.

The pinned upstream server is run as the official keyfactor/signserver-ce container under a systemd service that starts it on boot and restarts it on failure, backed by the image's embedded database on the same VM. The server exposes its public web, health endpoint and REST API on port 8080, and its administration console on port 8443 over mutual TLS. There is no administrator baked into the image: on first boot a unique administration certificate is generated for this VM and the administration console trusts only that certificate.

What is included:

• SignServer Community Edition 7.3.2 (official keyfactor/signserver-ce server image, pinned by digest), run by systemd
• The public web, health endpoint and REST API on :8080
• The administration console on :8443, reachable only over mutual TLS with the per-VM administration certificate
• A per-VM administration certificate (PKCS#12) and its keystore password generated on first boot and recorded in a root-only file
• A sample PlainSigner worker configured on first boot so you can verify a real signing operation immediately
• An embedded database, bound to the VM, holding the workers, keys and configuration
• docker.service and signserver.service as systemd units, enabled and active
• No baked-in administrator account and no shared secret between instances
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point; size up for heavier signing throughput. NSG inbound: allow 22/tcp from your management network, 8080/tcp for the public web and REST API, and 8443/tcp for the administration console. For production, front SignServer with your own domain and TLS. SignServer Community Edition is intended for evaluation and internal use.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SignServer by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22), 8080 and 8443. Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name signserver \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name signserver --port 8080 --priority 1010
az vm open-port --resource-group <your-rg> --name signserver --port 8443 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

SignServer runs as the signserver systemd service (a host-networked keyfactor/signserver-ce container). Confirm both services are active and that the server is listening on its web (8080) and administration (8443) ports:

systemctl is-active docker signserver
sudo ss -tlnp | grep -E ':8080|:8443' | awk '{print $4}' | sort -u

Expected output:

active
active
*:8080
*:8443

Step 5 - Retrieve your per-VM administration credentials

On the first boot of every VM, SignServer generates a unique administration certificate (a PKCS#12 keystore) and its keystore password, and records the location, the password and the administration URL in a root-only file. Read it with:

sudo cat /root/signserver-credentials.txt

There is no default or shared credential in the image: the administration console trusts only this VM's certificate, and no two instances share a secret. Import the PKCS#12 keystore (/root/signserver-admin.p12) into your browser or client to administer SignServer. Store the password somewhere safe.

Step 6 - Confirm the health endpoint, admin authentication and a real signing operation

SignServer exposes an unauthenticated health endpoint, an administration console protected by mutual TLS, and a REST signing API. Confirm the health endpoint returns 200 with body ALLOK, that the administration console rejects a request with no client certificate but accepts the per-VM certificate, and that the sample PlainSigner worker returns a signature:

curl -s -o /dev/null -w 'health:     %{http_code}\n' http://127.0.0.1:8080/signserver/healthcheck/signserverhealth
P12_PW=$(sudo grep '^SIGNSERVER_ADMIN_P12_PASSWORD=' /root/signserver-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'no cert:    %{http_code}\n' -k https://127.0.0.1:8443/signserver/adminweb/
sudo curl -s -o /dev/null -w 'per-VM p12: %{http_code}\n' --cert-type P12 --cert /root/signserver-admin.p12:"$P12_PW" -k https://127.0.0.1:8443/signserver/adminweb/
DATA=$(printf 'hello from my signing service' | base64)
curl -s -X POST -H 'Content-Type: application/json' \
  -d "{\"data\":\"$DATA\",\"encoding\":\"BASE64\"}" \
  http://127.0.0.1:8080/signserver/rest/v1/workers/PlainSigner/process | jq '{requestId, archiveId, signatureBytes: (.data | length)}'

Expected output (the administration console returns 200 only with the per-VM certificate, and the signer returns a base64 signature):

health:     200
no cert:    500
per-VM p12: 200
{
  "requestId": "-1064945680",
  "archiveId": "29d4355a36d40c34a1ab8db56abf3c84ba0a064e",
  "signatureBytes": 344
}

Step 7 - Sign in to the administration console

The administration console at https://<vm-public-ip>:8443/signserver/adminweb/ is protected by mutual TLS and trusts only this VM's administration certificate. Import the per-VM keystore into your browser first:

1. Copy the keystore off the VM: scp azureuser@<vm-public-ip>:/root/signserver-admin.p12 . (or sudo cp it to your home directory first if you are logged in as azureuser).
2. Import signserver-admin.p12 into your browser's personal certificate store, using the password from SIGNSERVER_ADMIN_P12_PASSWORD in the credentials file.
3. Browse to https://<vm-public-ip>:8443/signserver/adminweb/ and select the SuperAdmin certificate when prompted. Because the server uses a self-signed TLS certificate by default, accept the browser warning (or install your own TLS certificate for production).

The administration console opens on the SignServer overview, showing the server version and the workers configured on this VM.

Step 8 - Inspect the sample signer

The All Workers view above lists the workers configured on this VM: a sample CryptoTokenP12 crypto worker and a PlainSigner signer, both active. Select PlainSigner to see its status, crypto token, key and configuration. From here you view the signer certificate, run the built-in health checks, and adjust the worker's properties. This is where you configure real signers - PDF, XML, CMS or an RFC 3161 time stamp authority - each backed by a key in a crypto token.

Step 9 - Confirm the authorized administrator

Open Administrators to see who may administer this server. The only authorized administrator is this VM's SuperAdmin certificate, issued by the per-VM cloudimg SignServer ManagementCA, and the setting is Only listed - so the console can be reached only with the certificate generated for this VM on first boot. Add further administrators here and issue their certificates from your own management CA.

Step 10 - Sign your own data

The sample PlainSigner accepts data over the REST API and returns a signature, so you can wire signing into your own tooling immediately. Replace the sample worker with your own signers once you have loaded your keys:

DATA=$(printf 'contract v1 - sign me' | base64)
curl -s -X POST -H 'Content-Type: application/json' \
  -d "{\"data\":\"$DATA\",\"encoding\":\"BASE64\"}" \
  http://127.0.0.1:8080/signserver/rest/v1/workers/PlainSigner/process | jq -r '.data' | head -c 80; echo

This prints the start of the base64-encoded signature returned by the signer. In production you create a crypto token backed by your own keys (soft keystore, PKCS#11 HSM or a cloud key vault), add a signer worker of the type you need, and set its authentication so only your applications can call it.

Step 11 - Production hardening

The image ships the fully functional server, console and REST API with a sample signer. For production:

• Replace the sample signer: the bundled PlainSigner uses a sample test key and accepts unauthenticated requests for demonstration. Remove it, create crypto tokens backed by your own keys, and add signer workers with CLIENTCERT (or username/password) authentication so only your applications can sign.
• TLS and DNS: front SignServer with your own domain and a TLS-terminating reverse proxy or Azure Application Gateway, or install your own server certificate, so browsers and clients see a trusted certificate.
• Administrators: the per-VM SuperAdmin certificate is the initial administrator. Add further administrators from the console and issue their certificates from your own management CA.
• Durable database: the embedded database suits evaluation and small deployments. For heavier or highly available use, point SignServer at an external MariaDB or PostgreSQL database.

Maintenance

• Back up your data: the workers, keys and configuration live in the embedded database on the OS disk under /var/lib/signserver/persistent, and the per-VM administration keystore is at /root/signserver-admin.p12. Snapshot the OS disk to back both up.
• Administration URL: the console URL is set to the detected public IP on each boot and recorded in /root/signserver-credentials.txt. For a stable hostname or trusted TLS, front SignServer with your own domain.
• Security updates: unattended security upgrades are enabled, so the OS keeps itself patched. Reboot when a new kernel is installed.
• Upgrades: the server image is pinned for reproducibility; pull a newer keyfactor/signserver-ce tag and update the tag in /etc/systemd/system/signserver.service when you choose to upgrade.

Support

cloudimg provides 24/7/365 expert technical support for this image. Contact support@cloudimg.co.uk. SignServer Community Edition is licensed under the GNU LGPL-2.1 License. This image is provided by cloudimg; additional charges apply for build, maintenance and 24/7 support.