An internal library kiosk presents a self-signed TLS certificate with no public CA chain. What is the main trust implication compared with a certificate from a trusted third-party CA?
Select an answer to reveal the explanation.
Short Explanation
A self-signed cert is like a handmade visitor badge with no city hall stamp—you can still agree to honor it locally, but browsers will not treat it as publicly vouched. Trust is something you pin yourself, not something the public CA club hands you.
Full Explanation
A self-signed TLS certificate on an internal library kiosk is not validated through a publicly trusted certification authority chain. Public browsers and default trust stores will not automatically vouch for it. Any trust must be established explicitly—by installing the certificate or a local issuing root into the kiosk and management-approved trust stores, or by pinning in a controlled client set. Encryption of the session can still occur once endpoints trust that material, but public CA validation and the associated ecosystem assurances are absent.
Self-signed certificates do not automatically inherit trust from every public browser root store; that is precisely what they lack. They do not provide stronger non-repudiation than publicly trusted CA certificates; non-repudiation and third-party attestation are generally weaker or purely local without an external CA framework. The claim that self-signed certificates cannot encrypt traffic even when both endpoints explicitly trust them confuses trust distribution with cryptographic capability—TLS can encrypt under a locally trusted self-signed cert.
Exam caveat: self-signed means no public CA validation; trust is administrative and local, not globally inherited. Operational check: for citizen-facing or broadly used municipal services prefer publicly trusted or enterprise-CA certificates; if self-signed must be used on isolated kiosks, document the local root, restrict trust store changes, and monitor for unexpected certificate substitutions.