Shared Signing

Shared Signing lets a document owner send a PDF to multiple registered users for signing. Each participant reviews the document, applies their signature, and submits it back. The owner tracks progress and finalizes the document once all signatures are collected.

Shared Signing builds on storage. With the local storage provider it needs no license - just turn on security.enableLogin, storage.enabled, and storage.signing.enabled. The managed certificate options (Personal and Server certificates) require a Pro/Enterprise license; without one, participants sign by uploading their own certificate (P12/PKCS12 or JKS). The database and s3 storage providers also require a Pro/Enterprise license. See Modes for details.

What You Can Do#

• Invite multiple signers -- add registered users as participants to a signing session
• Flexible signing options -- participants can use the server certificate, their personal certificate, or upload their own (P12, JKS, PEM)
• Handwritten signatures -- participants can draw, type, or upload a wet signature overlay and place it on any page
• Track progress -- see who has signed, viewed, or declined in real time
• Summary page -- optionally append a page to the final PDF listing all signers, timestamps, and details
• Data cleanup -- sensitive signature and certificate data is automatically cleared from the server after finalization

Prerequisites#

security:
  enableLogin: true

storage:
  enabled: true
  signing:
    enabled: true

system:
  frontendUrl: https://your-stirling-instance.com
  serverCertificate:
    enabled: true

SECURITY_ENABLELOGIN=true
STORAGE_ENABLED=true
STORAGE_SIGNING_ENABLED=true
SYSTEM_FRONTENDURL=https://your-stirling-instance.com
SYSTEM_SERVERCERTIFICATE_ENABLED=true

How It Works#

Step 1: Create a Signing Session#

1. Open a PDF in the viewer
2. Click the Sign button in the Quick Access Bar
3. Click the + button next to Signature Requests
4. Add participants by selecting registered users
5. Optionally set a due date and configure signature display preferences
6. Review and submit

Session options:

Step 2: Participants Review and Sign#

Participants see pending sign requests under the Sign button in the Quick Access Bar after logging in.

From there they can:

1. Review the document and session details (due date, signature preferences)
2. Choose a certificate to sign with:

3. Add wet signatures (optional) -- draw, type, or upload a handwritten signature and position it on any page. Multiple signatures can be placed across different pages.
4. Submit their signature

Once submitted, the participant's status changes to Signed and they can no longer modify their submission.

Participants can also decline to sign, which marks their status as Declined.

Step 3: Track Progress#

The session owner can monitor progress from the Quick Access Bar or the session detail view:

• Signature count shown as "X/Y signatures" (e.g., "3/5 signatures")
• Color-coded badges: Blue (none signed), Yellow (some signed), Green (all signed -- ready to finalize)
• Per-participant status: Pending, Viewed, Signed, or Declined

The status auto-refreshes every 15 seconds.

Step 4: Finalize#

Once you've collected the signatures you need, click Finalize to produce the signed PDF.

What happens when you finalize:

1. All wet signature images are applied to the PDF at the positions each participant chose
2. If enabled, a summary page is appended showing each participant's name, email, status, timestamp, reason, and certificate type
3. Each participant's digital certificate is applied to the document
4. The signed PDF is saved and available for download
5. Sensitive data (signature images, certificate files, passwords) is permanently cleared from the server

Step 5: Download the Signed PDF#

After finalization, download the completed PDF from the session detail view or the Completed Sessions panel. The PDF contains all digital certificate signatures and wet signature overlays embedded in the document.

Security#

• One-time signing -- after signing or declining, participants are automatically downgraded to read-only access and cannot re-sign
• Certificate validation -- uploaded certificates are validated at submission time. Trust chain validation is configurable (see Certificate Signing)
• Audit trail -- all participant actions are recorded (viewed, signed, declined) with timestamps
• Post-finalization cleanup -- wet signature images, certificate files, and passwords are permanently removed from the database after finalization. Only the final signed PDF is retained

Configuration Reference#

Signing Settings#

storage:
  enabled: true
  signing:
    enabled: true              # Master switch for shared signing
    userListScope: org         # Who appears in the signer picker: 'org' (default) = whole instance, any other value = your own team only

system:
  frontendUrl: https://your-instance.com
  serverCertificate:
    enabled: true
    organizationName: My Company
    validity: 365              # Certificate validity in days
    regenerateOnStartup: false

STORAGE_ENABLED=true
STORAGE_SIGNING_ENABLED=true
STORAGE_SIGNING_USERLISTSCOPE=org
SYSTEM_FRONTENDURL=https://your-instance.com
SYSTEM_SERVERCERTIFICATE_ENABLED=true
SYSTEM_SERVERCERTIFICATE_ORGANIZATIONNAME="My Company"
SYSTEM_SERVERCERTIFICATE_VALIDITY=365

Who appears in the signer picker#

When you create a signing session, the participant picker lists the people you can invite. The storage.signing.userListScope setting controls who shows up:

The signer list is only ever shown to signed-in users, so no one can browse your user list without logging in, whichever scope you choose.

Certificate Validation Settings#

security:
  validation:
    trust:
      serverAsAnchor: true       # Trust server-generated certificates
      useSystemTrust: true       # Trust OS certificate store
      useMozillaBundle: true     # Trust Mozilla CA bundle
    revocation:
      mode: none                 # Options: none, ocsp, crl, ocsp+crl
      hardFail: false            # Fail if revocation check is inconclusive

See Certificate Signing - Configuration for detailed trust chain configuration.

Known Limitations#

• Participants must be registered users with accounts on your Stirling PDF instance
• Finalization can only be done once -- a session cannot be re-opened afterwards
• Each session covers a single document
• Digital certificates are applied in participant order during finalization
• The signature summary page is English-only

Troubleshooting#

Signature not appearing on the finalized PDF#

• Double-check the certificate type and password were entered correctly
• Check the Stirling PDF server logs for signing errors
• Make sure the source PDF is not corrupted or password-protected

Progress count not updating#

• The dashboard auto-refreshes every 15 seconds -- wait a moment and check again
• Check your browser's network tab for failed API requests

Wet signatures missing after finalization#

• Make sure the page numbers used are within the document's page range (pages start at 0)

"Group signing is disabled" when creating a session#

• Verify security.enableLogin: true, storage.enabled: true, and storage.signing.enabled: true in your configuration

Automation / API#

You don't need any of this for normal use - the whole workflow above runs from the app. This section is for developers who want to drive the signing workflow programmatically. The endpoints are listed below; see the API reference for full details.

Owner Endpoints (Authentication Required)#

Participant Endpoints (Authentication Required)#

Related#

• File Sharing and Storage -- Configure storage, sharing, and quotas
• Certificate Signing -- Individual certificate signing and validation
• Sign (Handwritten) -- Non-cryptographic visual signatures
• System and Security Settings -- Server certificates, JWT, sessions