Introduce a per-user certificate inventory and migrate legacy PFX storage

Open
  • Is something wrong?
#9,474 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
php
Domain
backend, security

Research direction

Start from SignEngineHandler, where the single signature.pfx filename is used, and trace how certificate creation, lookup and deletion assume one certificate per account. The work is a schema and storage design plus an idempotent migration, so read the existing storage code before proposing a data contract. Done means the acceptance criteria hold: existing PFX files are discoverable without reissuance, repeated migration is a no-op, accounts cannot read each other's material, and legacy signing still works.

Written by the indexing model from the issue text.

Description

backend enhancement php

Goal

Introduce a persistent inventory capable of representing multiple signing certificates per Nextcloud account, while preserving all existing reusable PFX certificates.

Current state

SignEngineHandler uses a single signature.pfx filename. Certificate creation, lookup and deletion assume one reusable certificate per account.

Scope

  • Introduce individual certificate records with stable identifiers and strict account ownership.
  • Store certificate metadata separately from protected PKCS#12 material.
  • Include issuer reference, subject, serial number, SHA-256 fingerprint, validity period, source, status and optional organizational context where applicable.
  • Support multiple inventory records for the same user without requiring multiple CAs.
  • Define a storage reference that does not expose private certificate material.
  • Migrate existing signature.pfx files idempotently, preserving their contents and password protection.
  • Retain compatibility with existing certificate lookup and signing paths during migration.
  • Establish backend contracts for later certificate-specific operations and UI development.
  • Avoid assuming that every certificate is LibreSign-issued or belongs to a Nextcloud group.

Acceptance criteria

  • Existing certificates are discoverable through the inventory without reissuance.
  • Two certificates belonging to one account have distinct records and protected storage references.
  • An account cannot retrieve another account's certificate material.
  • Repeated migration does not create duplicate records, overwrite PFX files or revoke certificates.
  • Listing certificate metadata does not require reading every PFX.
  • Missing files and inconsistent legacy records produce safe, recoverable behavior.
  • Tests cover ownership, migration, duplicate detection, storage failures and legacy signing compatibility.
  • The backend data contract and migration behavior are documented.

Out of scope

The complete CRUD UI, policy-based CA selection, certificate delegation, cloud certificates and interactive signing selection.

Dominant language
PHP
Stars
844
Forks
176
Avg merge
13h 46m
Merged PRs (30d)
299

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LibreSign/libresign

All issues in LibreSign/libresign

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.