The very first GUI visit shows a browser security warning, and the customer's security officer demands an explanation before anyone proceeds. What is the correct explanation?
Select an answer to reveal the explanation.
Short Explanation
That browser warning isn't a hack — it's the factory self-signed certificate announcing itself, which is exactly what it should do on a brand-new system. The encryption is fine; the trust chain isn't, and the fix is planned work, not panic. Replace it with a certificate your own CA signs for the real hostname, and the lock goes clean.
Full Explanation
Fresh appliances ship with a factory self-signed certificate because no trusted name or customer certificate authority exists yet at first boot. A browser warning is the normal, correct way an untrusted issuer gets surfaced — on a new system it is the expected state, not evidence of compromise. The planned follow-up during access work is to replace the factory certificate with one signed by the customer's CA for the system's real hostname; until then, sessions are encrypted but the trust chain is incomplete. Claiming the TLS handshake failed and the session is unencrypted fails on mechanism: a certificate warning presupposes a completed handshake presenting a certificate to complain about — the session is encrypted but unverified. A no-certificate plain-HTTP story is invented: management listeners serve TLS with the factory certificate from day one. Another customer's hostname on a factory certificate fails as a scare story, and renaming without issuing a matching certificate leaves the warning exactly where it was. Exam caveat: certificate replacement is the documented follow-on to first GUI access in the access task. Operational check: generate the signing request on the head, have the internal CA issue it for the management FQDN, install it, and reload the page to confirm a clean certificate chain.