Transit garage Windows clients must trust a newly issued municipal root CA. How should configuration management help?
Select an answer to reveal the explanation.
Short Explanation
A new city root CA is like issuing updated master credentials to every garage badge reader—done centrally, not by random blogs. Config management should push that trusted root. Turning off TLS validation is not a substitute.
Full Explanation
Transit garage Windows clients must trust a newly issued municipal root CA; configuration management should distribute that root CA certificate into the appropriate Windows trust stores across the client fleet. Central distribution keeps mechanics’ PCs and garage systems trusting municipal TLS services (software updates, VPN portals, inventory agents) without per-desk manual imports.
Asking each mechanic to browse to a personal blog and install random certificates is unsafe and non-scalable. Disabling TLS validation on garage clients so the new CA is unnecessary removes a core integrity control and invites man-in-the-middle risk on shop-floor networks. Emailing a ZIP of private keys to a shared garage distribution list confuses roots of trust with private key material and mishandles secrets—clients need the public root CA, not private keys, for trust.
Exam caveat: distribute the root (and intermediates if required) only through approved channels; verify thumbprints against the municipal PKI runbook. Computer store versus user store matters for machine-wide services. Pair CA distribution with monitoring that detects missing roots. Never bundle private keys with root distribution packages.
Operational check: deploy the new municipal root via config management to a pilot garage OU, confirm it appears in Trusted Root Certification Authorities for the computer account, validate TLS to an internal service signed under the new hierarchy, then roll out to remaining transit garage clients and revoke any temporary validation bypasses.