Two municipal court case-management systems must authenticate each other with mutual TLS. What PKI capability is most essential for that design?
Select an answer to reveal the explanation.
Short Explanation
Mutual TLS is a handshake where both sides show valid IDs, not just the server. That only works if a trusted CA family issues and can revoke those IDs. Without hierarchy and lifecycle management, mTLS is theater.
Full Explanation
Mutual TLS between municipal court case-management systems requires each endpoint to present a certificate the peer can validate to a trusted root. That depends on a trustworthy certificate authority hierarchy with controlled issuance, path validation, and working revocation—CRL or OCSP—so compromised or retired certificates stop being accepted. Managed PKI also covers naming constraints, key usage, and operational procedures for enrollment and renewal so court-to-court authentication remains cryptographic rather than ambient network trust.
A shared pre-shared key pasted into a wiki is not mTLS; it is a static secret with weak accountability, no per-host identity binding comparable to certificates, and high leak risk. IP allowlists prove network location assumptions, not cryptographic peer identity, and fail under spoofing, NAT, or relocated workloads. Accepting expired certificates without CRL or OCSP checks turns validation into theater and leaves revoked court identities usable.
Exam caveat: mTLS is only as strong as the PKI lifecycle behind it. CISSP treats trusted hierarchy, validation, and revocation as essential—not optional add-ons after enabling client certificates.
Operational check: issue distinct certificates to each case system from approved CAs; enforce certificate authentication on both sides; verify chain building to trusted anchors; enable revocation checking; alert on expiry; rotate and revoke on compromise; document which teams own enrollment for each court endpoint.