LDAP certificate ingestion is participant onboarding

What the public implementation shows

Guevara pages LDAP searches for userCertificate attributes, parses X.509 material, derives serial and common-name identity, resolves or creates participant records, and handles concurrent duplicate inserts.

The fetcher connects an external directory to the control-plane certificate and participant stores, while a background service repeats retrieval and validation on a fixed cycle. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleCertificate discovery changes the control plane, so identity matching and duplicate handling are part of the trust model.

The decision behind the mechanism

Serial number and certificate subject become durable trust evidence, and case-insensitive participant resolution reduces accidental duplicates during synchronization.

A certificate importer that ignores identity races can create duplicate participants, attach trust to the wrong institution, or stop the whole batch on one malformed entry. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Use paged directory searches and bounded processing.
• Match certificates to canonical participant identity.
• Treat serial duplicates and creation races idempotently.
• Validate expiry and revocation after ingestion.

How the control should be operated

Govern base DNs, bind credentials, transport security, page size, subject-to-participant rules, revocation, and health of the synchronization cycle.

Participant trust material can be refreshed centrally while individual bad records remain observable and contained. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.