A city CA issued a certificate that was later revoked after a private-key compromise. What should relying parties do before trusting that certificate?
Select an answer to reveal the explanation.
Short Explanation
Issuance is not a lifetime hall pass. After a CA says 'revoked,' clients need a fresh status check—CRL or OCSP—before they keep trusting that badge. Matching the name alone is not enough once the key is burned.
Full Explanation
Public-key infrastructure trust is continuous, not a one-time issuance event. After a city CA revokes a certificate because the private key was compromised, relying parties must learn that revocation status before treating the certificate as valid. Certificate Revocation Lists and Online Certificate Status Protocol (or equivalent stapling/status services) exist so browsers, VPN concentrators, and service clients stop trusting badges that were valid at issuance but are no longer trustworthy.
Trusting any certificate forever after the first CA signature verifies ignores the entire revocation lifecycle and leaves compromised keys usable until natural expiry. Accepting a certificate solely because the subject name matches, while ignoring revocation, validates identity presentation without checking whether the CA still stands behind that binding. Converting the certificate to a self-signed artifact so revocation lists no longer apply abandons the CA trust model and creates an untracked local trust exception rather than solving compromise response.
Exam caveat: name matching and chain validation are necessary but insufficient without current revocation checking when CRLs/OCSP are in play. Operational check: enable CRL or OCSP checking on municipal TLS clients and gateways, monitor status-service availability, shortlist emergency cert replacement after key compromise, and document how long cached status may be used during city outages.