Introduce a CA registry with stable issuer identity and legacy compatibility

未关闭
  • 哪里不对？
#9,475 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
12/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
php
领域
backend, security

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
PHP
星标
844
派生
176
平均合并
13 小时 46 分钟
30 天内合并 PR
299

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

LibreSign/libresign 的其他 Issue

查看 LibreSign/libresign 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。