A retail chain wants its guest Wi-Fi landing page served as guest.retailco.example with the company logo, colors and terms text, while ISE sits behind a load balancer address that differs from that name. Which portal configuration will present the trusted branded page to arriving guests?
Select an answer to reveal the explanation.
Short Explanation
For guests to trust your branded page, the name in their browser must match a certificate signed by a trusted CA. Point DNS to ISE, bind a CA-signed certificate for guest.retailco.example to the portal, and set that name there—the sign should match the door. ISE keeps the portal certificate separate from its administration certificate.
Full Explanation
ISE serves its portals over HTTPS using the certificate assigned to portal traffic, and the browser compares that certificate with the address in the address bar, so both must name the same host. Guests arrive at guest.retailco.example while the load balancer forwards to the node, so DNS for that name has to point at the ISE front end, the certificate must carry that exact name in its subject or subject alternative names, and the portal setting must advertise the same address so links and redirects agree. The administration-certificate approach fails because ISE keeps separate certificates for administration, portals and EAP, so the portal still presents its old identity. The self-signed approach fails because an untrusted chain raises a warning and a numeric address never matches the name on the certificate. The external-page approach fails because guest account creation, acceptable-use acceptance and login handling are portal services ISE must render itself. Exam caveat: a wildcard or multi-name certificate is fine as long as it covers the exact portal name and the chain includes intermediates. Check it in a private browser window by reading the certificate subject and chain.