Case study: onboarding a supplier
Summary. This page follows one complete flow from start to finish. A customer brings a new supplier into its supply chain, the two agree on a trust relationship, the supplier's first system is provisioned and opens the first protected connection to the customer's Database Gateway. Later one system is compromised and revoked, and finally the cooperation ends. The customer runs TrustBridge itself; the supplier, a small business, has an operating partner run its installation. The page shows who operates which components and who is responsible for what.
Terms
- Customer – a company that brings suppliers into its supply chain and grants them limited access to its services.
- Supplier – a partner whose systems receive certificates from the supplier's own hierarchy.
- Operating partner – a company that runs the supplier's installation within an agreed scope.
- Relying-party contract – the rules a verifying counterpart must follow for the security commitments to hold on its side.
- Initial provisioning – the first issuance for a system, when TrustBridge cannot yet recognize it by any certificate.
Parties
| Role | In this example | Operating model | Operates |
|---|---|---|---|
| Customer | Manufacturer H, Database Gateway data.h.example | Customer Managed | Its own TrustBridge installation, TLS adapter, and key agent in front of the gateway |
| Supplier | Supplier L, namespace l.example, system stock.l.example | Managed | Systems that generate their own keys; personal approval keys and custodians among its staff |
| Operating partner | Operating partner P | – | L's installation: CA worker, HSM partition, online services, monitoring |
Responsibilities
| Task | Customer H | Supplier L | Operating partner P |
|---|---|---|---|
| Agree on the relationship | Invites, defines its direction, approves | Checks H's anchor, defines its direction, approves | Sets up L's side technically |
| Build L's installation | – | Provides custodians for the root ceremony | Carries out the installation and the ceremony |
| Generate system keys | – | Does it | – |
| Approve L's orders | – | Does it | – |
| TLS adapter and key agent at L | – | Provides the host | Installs and monitors |
| Authorization in the Database Gateway | Does it | – | – |
| Revocation after a compromise | Revokes the relationship if it chooses to | Reports, instructs revocation | Carries out the revocation |
| End of the cooperation | Revokes its direction | Revokes its direction | Removes the relationship from L's installation |
From kickoff to the first connection
sequenceDiagram participant H as Customer H participant L as Supplier L participant P as Operating partner P participant SL as stock.l.example participant GH as TLS adapter and gateway H Note over H,P: Phase 1: installation at L P->>P: installation, keys in the HSM L->>P: custodians and approvers for the ceremony P->>P: L's root and issuing CA with nameConstraints l.example Note over H,L: Phase 2: relationship H->>L: invitation with H's anchor and fingerprint L-->>H: fingerprint confirmed over a second channel, L's anchor H->>H: direction H to L: service data.h.example, purpose, PQ required, duration L->>L: direction L to H: accept responses from data.h.example Note over L,SL: Phase 3: first certificate SL->>SL: generate key pair SL->>P: CSR via EST with one-time value L->>P: approval as a signature over the order hash P-->>SL: certificate and agent certificate Note over SL,GH: Phase 4: first connection SL->>GH: agents agree on the additional secret SL->>GH: TLS 1.3 with certificate, PSK, and hybrid group GH->>GH: chain, nameConstraints, revocation status, policy GH->>GH: gateway checks the rule for L GH-->>SL: released data
| Phase | Critical point | How TrustBridge handles it |
|---|---|---|
| 1 Installation | The operating partner must not be able to issue in L's name | Approvers and custodians are exclusively L's people; the HSM partition is assigned to L alone |
| 2 Relationship | The other side's anchor must not be swapped in transit | Fingerprint over a second channel; added only with a person's approval |
| 2 Relationship | H wants to open exactly what L needs and nothing more | Policy per direction: one service, one purpose, one duration |
| 3 First certificate | L has to prove its system is genuine | One-time value with an expiry, handed to the responsible person through a separate channel |
| 4 Connection | A certificate is not an authorization | The gateway authorizes every request against its own rule |
Day-to-day operation
The certificates of stock.l.example and its key agent renew automatically over EST once only a
third of their lifetime remains. The key agents of L and H renew their shared secret every ten minutes;
the TLS adapters rotate the connection after an hour at the latest, without L's application noticing
any interruption.
Compromise and revocation
sequenceDiagram participant L as Supplier L participant P as Operating partner P participant W as L's CA worker participant H as Customer H participant GH as TLS adapter H L->>P: report: stock.l.example compromised L->>P: revocation order approved P->>W: revoke system and agent certificates W->>W: revocation in the ledger, new CRL L->>H: notice of the incident GH->>GH: new CRL loaded, certificate rejected H->>H: optional: suspend the relationship until resolved
From the next fetch cycle at the latest, the certificate is useless at H. If H wants to act faster, it suspends its direction of the relationship; the new trust bundle reaches its TLS adapters immediately. If L's database fails in the meantime, P revokes at the console of L's worker host, with the approval of one of L's people.
End of the cooperation
H revokes its direction of the relationship. From that moment no new connections from L are accepted; existing ones end within the period set in the policy. L revokes its direction as well. L's certificates remain valid for its relationships with other customers. Both organizations keep their ledgers and connection logs as evidence.
If L later changes operating partner or takes over operations itself, a new CA generation is created in the new environment, and H adds its anchor to the relationship. No private keys are handed over in the process.
Connection variants
| Variant | How it works | Effort for the customer |
|---|---|---|
| Supplier with its own installation (as above) | Bilateral relationship between two installations | One relationship per supplier |
| Supplier without its own installation | H issues a partner CA in its own hierarchy, name-constrained to l.example; L's staff approve through the partner portal | A ceremony for the partner CA; one relationship per supplier |
| Supplier with an existing enterprise PKI | L brings its PKI's anchor into the relationship and equips the systems involved with a TLS adapter and key agent | Review of the external anchor and its name constraints before adding it |
In the third variant, the commitments on approval, ledger, and status information apply to the certificates that TrustBridge itself issues. Issuance within the existing PKI remains the supplier's operational responsibility.
What this case study does not show
- How contracts between customer, supplier, and operating partner are drafted.
- The individual rules of the Database Gateway; those are described in the gateway's documentation.
- Connecting several sites of one supplier; that follows the same pattern, with one namespace per site.