A hotel chain is launching sponsored guest Wi-Fi through ISE: staff create accounts in the sponsor portal, and printed QR codes must open a branded page at connect.hotel.example.com. Both portals must run over HTTPS, with the padlock validating cleanly on supported guest devices with current trust stores. Which portal setup serves both pages at the printed name with a clean padlock?

The setup that publishes connect.hotel.example.com in DNS and binds an HTTPS portal certificate whose SAN includes that exact name is correct: DNS sends guests to the intended service, and a trusted certificate matching the printed hostname lets supported devices validate the site and show a clean padlock. Publishing the printed name with a matching certificate but hosting the sponsor portal at sponsor.hotel.example.com leaves that portal at a different address, so it does not serve both pages at the printed name. Using a publicly trusted certificate for guest access while the sponsor certificate covers only sponsor.hotel.example.com also fails: trust in the issuer does not make the sponsor certificate valid for connect.hotel.example.com, and browsers can warn when the names do not match. Binding a publicly trusted *.example.com certificate to both portals does not solve the mismatch, because that wildcard covers a single label such as hotel.example.com, not the two-label hostname connect.hotel.example.com. Exam caveat: check the SAN against the complete requested hostname; a trusted issuer alone is insufficient, and wildcard matching is limited by label depth. Practical check: from representative supported guest devices, open both portals at the printed URL and verify the address, certificate SAN, trust chain, and absence of browser warnings.