Introduce a CA registry with stable issuer identity and legacy compatibility

Open
  • Is something wrong?
#9,475 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

The payload names no files, classes or tests, so start by finding where the active CA's configuration and identifiers are read during certificate issuance and CRL generation. Map the legacy instanceId, generation and engineType values to the proposed registry record. Done means a documented registry contract, legacy CA representable without key or certificate changes, and tests for isolation, identity collisions and invalid issuer lookup. This is design-heavy, so confirm scope with maintainers first.

Written by the indexing model from the issue text.

Description

backend enhancement php

Goal

Establish the backend registry and identity contract needed to manage multiple certificate authorities in one LibreSign installation.

Current state

The active CA is represented by application-level configuration and identifiers used throughout certificate issuance and CRL services.

Scope

  • Define a persistent CA record with an opaque public issuer identifier.
  • Represent CA identity, engine type, generation, lifecycle state and protected storage references.
  • Preserve the existing installation's CA without regeneration or certificate reissuance.
  • Support more than one registered CA, while leaving policy-based selection and administration UI for subsequent work.
  • Define how organizational contexts may reference a CA without using the Nextcloud group ID as its cryptographic identity.
  • Establish the identifier contracts needed by issuance, certificate inventory, revocation and CRL distribution.
  • Keep historical instanceId, generation and engineType information available for compatibility.
  • Define and verify the issuer-scoped identity of certificates, including cases where different issuers use the same serial number.
  • Establish backend ownership and authorization boundaries for privileged CA operations.

Acceptance criteria

  • Legacy CA configuration can be represented in the registry without changing its keys or issued certificates.
  • Multiple CA records have stable, unambiguous issuer identifiers.
  • A CA can be referenced independently of a group's name or lifecycle.
  • Missing or unauthorized issuer references fail safely.
  • Tests cover registry isolation, legacy compatibility, identity collisions and invalid issuer lookup.
  • Existing CRL URLs and certificate validation behavior remain unchanged.
  • The CA registry contract is documented for subsequent implementation.

Out of scope

New CRL routes, complete multiple-CA issuance, group administration UI, delegated CA creation and changes to signer certificate subject policies.

Handoff

Review the multi-CA epic's remaining implementation requirements against the registry contract before opening detailed CRL, provisioning and policy-selection issues.

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.