Skip to content
QCecuring Documentation

On-Premises Installation

Overview

Section titled “Overview”

On-premises deployment is recommended for enterprises with strict security, compliance, or regulatory requirements.

This model provides:

  • Full control over signing infrastructure
  • Isolation from external networks
  • Integration with internal PKI and HSMs

Deployment Model

Section titled “Deployment Model”

Recommended components:

  • API Layer — auth, policy enforcement, and request intake (behind TLS/mTLS)
  • Job Queue — e.g., RabbitMQ or Kafka for async processing
  • Workers / Signing Engine — stateless services that consume jobs and call HSMs
  • HSM / KMS — on-prem HSM (PKCS#11) or cloud KMS for key protection
  • Metadata & Audit Store — database (Postgres / Mongo) for policies, key metadata, and immutable audit logs
  • Portal / Approvals — UI for approvers and administrators

Network placement:

  • Place public-facing endpoints (if any) behind an ingress with WAF rules.
  • Use internal L2/L3 segmentation for trust boundaries; HSMs should live on a restricted management network.

Prerequisites

Section titled “Prerequisites”

Infrastructure:

  • Dedicated Linux hosts or an orchestrator (Kubernetes) with sufficient resources.
  • Recommended minimum per service: 2 CPU, 8 GB RAM (adjust per load tests).
  • Persistent storage (for audit logs, database, and backups).

Software & tools:

  • Java 17+ (or platform runtime)
  • Container runtime or orchestration (Docker, Kubernetes optional)
  • Database (Postgres or MongoDB as per deployment reference)
  • Message broker (RabbitMQ / Kafka)

Network & security:

  • TLS certificates issued by your internal CA
  • mTLS for agent and internal service communication where appropriate
  • Firewall rules limiting access to HSM and management ports

Compliance & validation:

  • HSMs certified to FIPS 140‑2 Level 2+ (or equivalent) for production
  • Certificate lifecycle planning (460-day validity considerations)

Installation Steps

Section titled “Installation Steps”

  1. Prepare hosts and networking

    • Harden OS according to your baseline
    • Configure NTP / time sync across all nodes
    • Create service accounts and apply least privilege

  2. Deploy platform services

    • Deploy API, workers, policy store, and portal via containers or system packages
    • Apply TLS and authentication middleware (mTLS where applicable)

  3. Configure Key Storage

    • Prefer generating keys inside the HSM or KMS
    • If using on-prem HSM, install PKCS#11 module on agent/worker hosts and configure access
    • If using cloud KMS, configure IAM roles and network connectivity

  4. Onboard signing certificates

    • Import the certificate chain into the platform
    • Associate certificates with HSM-protected keys
    • Enforce EKU: Code Signing when issuing certificates

  5. Configure Policies & Quorum Approvals

    • Define signing policies (time windows, allowed key usage)
    • Configure approver groups and minimum counts for quorum workflows

  6. Enable Logging, Monitoring & Alerts

    • Expose health endpoints (/actuator/health/*) and Prometheus metrics
    • Forward audit logs to a SIEM or centralized logging system
    • Configure alerts for HSM unavailability, queue depth, and error spikes

HSM Integration Patterns

Section titled “HSM Integration Patterns”
  • Direct PKCS#11: Workers load PKCS#11 module and call HSM directly (low latency).
  • Agent-proxy: Agents near CI/CD or developer hosts act as PKCS#11 shims and forward signing requests over mTLS to central workers.
  • Cloud KMS: Use managed KMS for SaaS/Hybrid; bind keys to service identities and restrict key use to signing operations.

Refer to the HSM setup guide for SoftHSM examples and vendor recommendations.

Validation & Smoke Tests

Section titled “Validation & Smoke Tests”

After deployment, validate with the following steps:

  • Service health:

    • curl -sS https://<api>/actuator/health | jq .
    • curl -sS https://<api>/actuator/health/hsm

  • Test signing end-to-end (digest example):

    • Compute digest:
      Terminal window
      openssl dgst -sha256 -binary myapp.exe > digest.bin
      base64 digest.bin > digest.txt
    • Submit request to the API (sync or async):
      Terminal window
      curl -sS -X POST https://<api>/api/v1/sign/digest -H "Authorization: Bearer $TOKEN" -d '{"digest":"<base64>","metadata":{"filename":"myapp.exe"}}'
    • Verify returned signature locally and ensure timestamp tokens are recorded if configured.

  • Verify audit logs and approvals appear in the portal.

Operational Considerations

Section titled “Operational Considerations”
  • Key rotation: Plan for rotation and automated renewal; verify apps can handle rotated keys.
  • HA & Failover: Plan for worker autoscaling and HSM redundancy (where supported by vendor).
  • Backups & DR: Backup metadata and config; HSM private keys typically cannot be exported—plan HSM backups per vendor guidance.
  • Performance: Measure HSM signing latency and size worker pools accordingly.

Security Notes

Section titled “Security Notes”
  • Ensure admin vs signer separation of duties (RBAC).
  • Use short-lived credentials for CI/CD and rotate them frequently.
  • Protect audit logs and ensure immutability where compliance requires it.

Troubleshooting

Section titled “Troubleshooting”

See Troubleshooting for common diagnostics and commands.

Checklist

Section titled “Checklist”
  • Hosts provisioned and hardened
  • HSM or KMS provisioned and accessible
  • TLS and mTLS configured
  • Services deployed and health checks pass
  • Test signing verified end-to-end
  • Audit logs forwarding and monitoring enabled

See also: HSM Setup, Signing Workflows, Operations → Troubleshooting.