An internal web tool at a factory presents a certificate the server signed itself, and browsers warn even though the session is encrypted. Which change removes the warning without giving up encryption?
Select an answer to reveal the explanation.
Short Explanation
A locked box with a note that says to trust the writer of the note is still locked, and you are right to hesitate. The factory tool is encrypted with a certificate it signed itself, so browsers warn because they do not trust the signer. Replace that certificate with one chained to a certificate authority the browsers already trust, and leave the encryption on.
Full Explanation
A self-signed certificate can still encrypt the session. The browser warning appears because the certificate does not chain to a certificate authority the browser already trusts. The fix that keeps encryption and removes the warning is a certificate issued by an authority those browsers trust, with a name that matches the site. Disabling TLS would silence the warning and would also remove the encryption the stem says to keep. Extending the lifetime of the same self-signed certificate leaves the untrusted signer in place. The warning is about who signed it, not about an expired date the stem never mentions. A publicly issued certificate is the other near miss, because the issuer can be trusted, and a name that does not match the tool still fails validation. The browsers keep warning. Exam caveat: an internal authority works only after its root is in the browsers' trust stores. A chain that ends at an authority nobody trusts warns the same way a self-signed certificate does. Operational check: browse the tool, confirm the certificate name matches the site, confirm the chain ends at a trusted authority, and confirm the warning is gone.