The internal admin dashboard had been running on a self-signed certificate since the company's earliest days — a reasonable enough original choice for an internal-only tool nobody outside the company would ever visit. The trouble was, "internal-only" had grown from three founding engineers to a much larger team, and every new hire's first week now reliably included the same ritual: hit the certificate warning, ask in Slack whether that was expected, get told yes, click through it.
Why it took so long to actually fix
Nobody had ever treated the certificate warning as an active problem, exactly — it was more of an accepted, faintly embarrassing quirk. The actual cost of it was diffuse and hard to point at directly: a few minutes of every new engineer's onboarding, a recurring "is this supposed to happen" question, and a general normalization of clicking through certificate warnings that sat uncomfortably alongside the company's own security training materials, which told everyone never to do exactly that on any other site.
That last point was what actually got it prioritized. A new security engineer, going through onboarding herself, pointed out the specific contradiction: the company's own training explicitly taught people to distrust certificate warnings, while the company's own internal tooling was training the same people to ignore that instinct in one specific, memorized case. That framing — not the certificate warning itself — was what got budget allocated to fix it properly.
What "fixing it properly" actually meant
Rather than just buying a normal publicly-trusted certificate (which doesn't cleanly work for infrastructure that isn't meant to be internet-reachable at all), the team stood up a small internal certificate authority — generating their own root certificate, distributing it via the company's existing device management system so every company laptop trusted it automatically, and issuing genuinely valid-looking internal certificates from that root for every internal tool going forward, not just the admin dashboard.
The actual payoff
New engineers now see a clean padlock on internal tools from day one, with zero certificate-warning ritual to explain. More substantively, the internal CA setup gave the team a foundation for later doing real mutual TLS between internal services — using the same trusted root to issue client certificates as well as server ones — which hadn't been practical to bootstrap cleanly under the old self-signed, ad-hoc approach. Our self-signed certificate guide covers why browsers warn about this pattern in the first place, and our mutual TLS guide covers the client-certificate piece that became possible once a real internal CA existed.
This case study is written to illustrate a genuine, common troubleshooting pattern. It is not a direct quotation or a verified account tied to a specific, identifiable individual or company. For the underlying technical reference, see: Generating a Self-Signed Certificate for Local Development · Setting Up Client Certificate Authentication
Loading comments…