# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## BMTLS — Mutual TLS certificate lifecycle A fictional internal report exporter uses mutual TLS. Certificates are renewed manually, and operators cannot distinguish peer identity failures from network outages. **Field:** Networking. **Suggested stack:** TypeScript, TLS, Local certificate fixtures. **Engineer value:** Practice transport identity, trust-store changes, and certificate failure diagnosis. **Company value:** Provide repeatable rotation and recovery behavior for authenticated service communication. **Delivery agreement:** Deliver local TLS checks and lifecycle rehearsals; modify no real trust stores. ### Setup prerequisites - Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. ### Define peer identity Specify certificate and name constraints. #### BMTLS-101 — Define expected service names and certificate usage **Task · Medium priority · Foundational** noCV practice brief v5 · BMTLS-101 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define peer identity. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Networking 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A certificate signed by the internal CA is accepted for any service name. Acceptance criteria - List expected subject alternative names per peer. - Declare client and server usage requirements. - Separate trust-chain validity from service identity. Implementation constraints - Use reserved local names and test certificates. Verification - Match the intended service identity. - Reject a valid-chain certificate for another service. Deliverables - TLS identity contract. Rollout and recovery: Review identities before enabling peer authentication. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-102 — Validate certificate chains without disabling hostname checks **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-102 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define peer identity. Depends on: BMTLS-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Networking 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A workaround accepts self-signed certificates by disabling all verification. Acceptance criteria - Trust only the configured test CA set. - Verify peer names and intended usage. - Reject expired, incomplete, and unknown chains. Implementation constraints - No permissive verification bypass is allowed. Verification - Connect with the authorized test chain. - Reject wrong-name and untrusted certificates. Deliverables - Strict TLS configuration. Rollout and recovery: Fail closed and expose safe diagnostic categories. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Enforce transport trust Validate peers and handle connection lifecycle. #### BMTLS-103 — Separate certificate expiry alerts from connection failure rates **Task · Medium priority · Intermediate** noCV practice brief v5 · BMTLS-103 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Security 20% · Networking 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Renewal is noticed only when connections begin failing. Acceptance criteria - Report remaining certificate lifetime. - Distinguish leaf and trust-anchor expiry. - Keep expiry observations separate from availability outcomes. Implementation constraints - Avoid private-key or full certificate dumps in generic logs. Verification - Observe a near-expiry leaf certificate. - Show an expired CA distinctly from an unreachable peer. Deliverables - Certificate health metrics. Rollout and recovery: Run read-only checks before wiring operational alerts. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-104 — Refresh connection pools after client-certificate rotation **Bug · High priority · Advanced** noCV practice brief v5 · BMTLS-104 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-102, BMTLS-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Networking 50% · Security 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Long-lived connections keep using the old client identity after new credentials are loaded. Acceptance criteria - Bind pools to certificate generation. - Stop assigning new requests to retired pools. - Drain existing connections within a declared deadline. Implementation constraints - Do not terminate healthy requests without the documented drain policy. Verification - Rotate while a request is active. - Verify new connections use the new certificate generation. Deliverables - Certificate-aware pool lifecycle. Rollout and recovery: Roll out with a bounded overlap; preserve prior public trust during drain. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-105 — Keep TLS errors from exposing peer secrets or request payloads **Task · High priority · Intermediate** noCV practice brief v5 · BMTLS-105 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce transport trust. Depends on: BMTLS-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 30% · Networking 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Handshake errors include large diagnostic objects containing sensitive material. Acceptance criteria - Map failures to bounded safe categories. - Include correlation and expected peer class. - Exclude private keys, tokens, and request bodies. Implementation constraints - Use seeded synthetic secret markers. Verification - Diagnose hostname and expiry failures. - Verify secret markers never appear in logs. Deliverables - Safe TLS error mapping. Rollout and recovery: Replace broad error serialization before expanding diagnostics. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Rehearse certificate changes Test overlap, expiry, revocation, and recovery. #### BMTLS-106 — Rehearse leaf renewal under an unchanged trust anchor **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-106 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-104, BMTLS-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Networking 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Routine renewal should not require every client to restart simultaneously. Acceptance criteria - Issue a new leaf with the same declared identity. - Overlap old and new leaves within policy. - Verify old-leaf retirement after draining. Implementation constraints - Generated keys remain local temporary test assets. Verification - Renew without interrupting the declared local request flow. - Reject the expired prior leaf after overlap. Deliverables - Leaf renewal rehearsal. Rollout and recovery: Renew before expiry and retain a bounded rollback window. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-107 — Rotate trust anchors without accepting unrelated authorities **Task · High priority · Advanced** noCV practice brief v5 · BMTLS-107 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Networking 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Adding a new CA to the trust store accidentally imports every certificate from a shared bundle. Acceptance criteria - Allowlist exact old and new test anchors. - Stage verifier trust before switching issuers. - Remove the old anchor after the declared overlap. Implementation constraints - Never trust an arbitrary system bundle for this private service boundary. Verification - Complete a staged CA rotation. - Reject a third unrelated CA throughout the overlap. Deliverables - Trust-anchor rotation procedure. Rollout and recovery: Keep overlap short and reviewed; fail closed on unexpected trust material. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-108 — Enforce peer revocation on reused connections **Bug · High priority · Advanced** noCV practice brief v5 · BMTLS-108 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-104, BMTLS-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Networking 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A revoked peer retains a long-lived authenticated connection. Acceptance criteria - Define revocation checks and maximum connection lifetime. - Stop new requests for revoked peer identity. - Close or drain existing connections according to the incident policy. Implementation constraints - Revocation policy must state its bounded enforcement delay. Verification - Revoke an idle authenticated peer. - Attempt reuse and verify denial within the declared bound. Deliverables - Revocation enforcement tests. Rollout and recovery: Rehearse revocation before relying on certificate identity for sensitive operations. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-109 — Compare certificate overlap availability against retained trust risk **Task · High priority · Expert** noCV practice brief v5 · BMTLS-109 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-107, BMTLS-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Site reliability 30% · Networking 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A long overlap helps slow clients but extends acceptance of old credentials. Acceptance criteria - Model client refresh distribution and enforcement delay. - Compare bounded overlap options. - Document unknown client behavior and recovery implications. Implementation constraints - The local rehearsal cannot prove organization-wide certificate rollout coverage. Verification - Evaluate fast and delayed synthetic clients. - Reject an overlap proposal without an explicit old-trust retirement point. Deliverables - TLS lifecycle decision record. Rollout and recovery: Choose a measurable overlap and track lagging clients before retirement. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### BMTLS-110 — Write a certificate-expiry incident handoff **Chore · Low priority · Foundational** noCV practice brief v5 · BMTLS-110 · Mutual TLS certificate lifecycle Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse certificate changes. Depends on: BMTLS-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Security 30% · Networking 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. On-call staff need a safe response when one peer fails certificate validation. Acceptance criteria - Identify failing peer class and certificate generation. - Show approved renewal and trust-check steps. - Explain when to stop retries and escalate ownership. Implementation constraints - Never recommend disabling certificate verification. Verification - Resolve a synthetic expired leaf using the guide. - Keep an unknown-CA failure closed. Deliverables - TLS support runbook. Rollout and recovery: Store with the service identity inventory and rotation schedule. Project prerequisites: Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys. Engineer value: Practice transport identity, trust-store changes, and certificate failure diagnosis. Company value: Provide repeatable rotation and recovery behavior for authenticated service communication. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.