ECA-15056: REST API: DELETE /v1/certificate/{issuer_dn}/{certificate_serial_number}

[John-D-B]

Pull Request: Fix 26: REST endpoint: DELETE revoked certificates

Target title:

ECA-15056: REST API:

    DELETE /v1/certificate/{issuer_dn}/{certificate_serial_number}

Author: JohnB, with AI pair-programming support by Anthropic Claude Code (Opus, 1M-context)

Target branch: main

Source branch: fix-26-rest-delete-certificate

Depends on:

Fix 27 PR — #1054.

This branch carries only the REST-layer change; the EJB primitive it calls,

    deleteRevokedCertificate(...), is added by Fix 27.

Apply #1054 first — this endpoint will not compile against a tree without it.

---

FYI: Customer EE feature request, accepted by Keyfactor engineering

• EE support ticket #172467:
  
  https://support.keyfactor.com/hc/en-us/requests/172467
  
  "Need a mechanism to 'reap' (delete) revoked certificates from K8s certmanager churn."
  
  Marked solved by Keyfactor support after engineering accepted the request.

• Engineering reference: ECA-15056
  
  (assigned 25 May 2026, tracked via Customer Success Manager).

• Why this PR exists:
  
  The customer, having had the request accepted as an engineering task,
  
      is offering a working implementation rather than waiting in the EE backlog queue.
  
  Submitted into CE because that's the public contribution surface; the vendor's CE→EE propagation flow takes it from there.

• Two PRs total:
  
  — Fix 27: the foundation DBMS Worker option
  
  — Fix 26: the on-demand REST equivalent (this one)

---

Summary

Adds a new endpoint to the REST API:

    DELETE /v1/certificate/{issuer_dn}/{certificate_serial_number}

Permanently deletes the database row for a certificate that is already in REVOKED status.

The endpoint is the on-demand equivalent of the scheduled bulk-delete

    provided by the Database Maintenance Worker's Delete Revoked Certificates option

    (added in the companion Fix 27 PR).

It exists for operator-driven cleanup and customer-tooling integration,

    for cases that the worker's schedule-based model doesn't cover.

This is part (b) of ticket #172467 / engineering reference ECA-15056

    (Keyfactor engineering accepted 25 May 2026).

FYI: ELT status codes

$ ejbca-lifecycle-tool.py --help | less
  ...
  status codes (cert table 'S' column and count-line breakdown):
    A   active                  — certificate is not revoked, not expired
    E   expired (not revoked)   — cert is past notAfter, never revoked
    R   revoked + expired       — cert is revoked AND past notAfter (prunable from CRL)
    r   revoked + unexpired     — cert is revoked, still within validity (CRL must carry)
    ?   unknown                 — status doesn't map to the four above

  Count-line example (list -d4):
    Certificates:  35:  1:A active,  7:E expired,  20:R revoked+expired,  7:r revoked+unexpired

External references

The "Fix-26" and "Fix-27" terms come from earlier work with JohnB's EJBCA Lifecycle Tool (ELT):

• https://github.com/John-D-B/Claudes/blob/main/2026-06-01.EJBCA-tools/elt/insights/CLAUDE-ejbca-fix-requests.md
• https://github.com/John-D-B/Claudes/blob/main/2026-06-01.EJBCA-tools/elt/README-elt.md

A user-visible demonstration of PKI workflow for this pull request is in JohnB's repository:

• https://github.com/John-D-B/Claudes/blob/main/2026-06-01.EJBCA-tools/README.md

A PowerPoint overview is here:

• https://github.com/John-D-B/Claudes/raw/main/2026-06-01.EJBCA-tools/ppt/EJBCA-CE-PR-workflow-demo.pptx