SignServer CE

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size. Choose a larger size for heavier signing throughput.

Configure the network security group (NSG) to allow inbound 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 SecureAnyCloud, and select Create.

On the Basics tab, 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.

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms, create the VM and open ports 8080 and 8443:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:signserver-ce-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name signserver \
  --image sac1647283583153:signserver-ce-ubuntu-24-04:default:latest \
  --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

Connect over SSH as azureuser.

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

SignServer runs as the signserver systemd service, which wraps a host-networked keyfactor/signserver-ce container. Confirm that both services are active and that the server listens 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

The output looks like this:

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. It records the keystore location, the password and the administration URL in a root-only file. Read the file with:

sudo cat /root/signserver-credentials.txt

The image contains no default or shared credential. The administration console trusts only this VM's certificate, and no two instances share a secret.

To administer SignServer, import the PKCS#12 keystore (/root/signserver-admin.p12) into your browser or client. Store the password somewhere safe.

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

SignServer exposes an unauthenticated health endpoint, an administration console protected by mutual TLS, and a REST signing API. The commands below check three things:

• The health endpoint returns 200 with body ALLOK.
• The administration console rejects a request with no client certificate and accepts the per-VM certificate.
• 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)}'

The output looks like this. 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:

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

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

Step 8 - Inspect the sample signer

Open the All Workers view. It 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 can view the signer certificate, run the built-in health checks and adjust the worker's properties.

This is also 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 SecureAnyCloud SignServer ManagementCA. 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. Once you have loaded your keys, replace the sample worker with your own signers.

Sign a string with the sample worker:

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

The command prints the start of the base64-encoded signature returned by the signer.

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

Step 11 - Production hardening

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

• Replace the sample signer. The bundled PlainSigner uses a sample 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 that only your applications can sign.
• Set up 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 that browsers and clients see a trusted certificate.
• Manage 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.
• Use a 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 up both.
• Check the administration URL. On each boot, the console URL is set to the detected public IP and recorded in /root/signserver-credentials.txt. For a stable hostname or trusted TLS, front SignServer with your own domain.
• Keep the OS patched. Unattended security upgrades are enabled, so the OS keeps itself patched. Reboot when a new kernel is installed.
• Upgrade deliberately. The server image is pinned for reproducibility. To upgrade, pull a newer keyfactor/signserver-ce tag and update the tag in /etc/systemd/system/signserver.service.

Support

SecureAnyCloud provides 24/7/365 expert technical support for this image. Contact sales@secureanycloud.com.

SignServer Community Edition is licensed under the GNU LGPL-2.1 License. This image is provided by SecureAnyCloud, and additional charges apply for build, maintenance and 24/7 support.

Deploy on Azure

Launch SignServer Community Edition on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com