Hermes Wiki
opportunities/2026-08-24-incremental-rbc-work

Incremental Opportunities: RBC_Work (2026-08-24)

Scope: Architecture/Fundamentals/public-key-infrastructure-and-certificates (new this window) against Projects/RBC_Work.md line 51's "production, SSL certification, automation for 3100+ silver peak devices built in hours and executed in a single change."

Finding

Projects/RBC_Work.md names one of its concrete production wins as automating SSL certification across 3,100+ SilverPeak devices in a single change — already flagged in an earlier opportunity pass (opportunities/2026-08-19-incremental-RBC_Work) as structurally similar to the open-source cisco_ios_selfsigned_cert_role project. Neither note has yet connected this to the underlying PKI design question, because until this window the vault had no vendor-neutral PKI note to connect it to.

Architecture/Fundamentals/public-key-infrastructure-and-certificates's tradeoff table draws a direct line to what "3,100+ devices, one change" actually implies architecturally: this can only be a private/internal CA operation at that device count and that change velocity — no public CA (ACM, Let's Encrypt) issues certificates for internal network-device identity at that scale in one automated batch. The note's own root-custody question — "who holds the private key for the root, how is it protected, and what's the blast radius if it's compromised?" — is precisely the question a bank's internal network PKI needs a defensible answer to, and the note's short-lived-vs-long-lived tradeoff (automated rotation vs. a wide compromise window) is directly relevant to whether "3,100+ devices in one change" was a one-time bulk issuance or the first run of an ongoing automated rotation pipeline.

The note's "Common pitfall" section — treating certificate expiry as a monitoring afterthought, which causes fleet-wide simultaneous outages with no code change involved — is a specific, checkable risk against a fleet this size: if the 3,100+ SilverPeak certs were bulk-issued with a uniform validity window, they also share a uniform expiry cliff unless staggered or continuously rotated, which is exactly the "nobody touched anything, a cert issued a year ago simply ran out the clock" failure mode the note warns is one of the most common causes of full outages with no code change.

Suggested next step

Worth surfacing as a specific question the next time the SilverPeak cert automation (or its net certifier agent / golden-image certification siblings, items #2 and #8 in RBC_Work's list) comes up for review: (1) is the root CA for this device fleet a dedicated internal CA (Vault PKI, a self-hosted step-ca, or a Microsoft/other enterprise CA) with documented root-key custody, or issued through a shared corporate CA with a broader blast radius than this one use case needs; (2) are the 3,100+ certs on a uniform, monitored rotation cadence with alerting well before expiry (30+ days, per the Fundamentals note's guidance), or was the "single change" a one-time bulk issuance that will eventually recreate the same all-at-once expiry risk it was built to fix. Both are the kind of "how would this fail, and did we design that out" questions that separate a working automation from a durable one.

Hermes Wiki