Hotel guests reach the captive portal and the browser warns that the portal certificate is not trusted. The portal page is otherwise the right one. What should be installed?
Select an answer to reveal the explanation.
Short Explanation
The guests found the right page, and the browser does not believe the certificate on it. Install a certificate from an authority their devices already trust. Your staff passphrase does not sign that page.
Full Explanation
A captive portal presented over HTTPS has to use a certificate the guest device trusts, or the browser warns and many guests stop. A warning on the right page is still a failed portal for most of your guests. The page is the right one, so the fix is a portal certificate from a public or otherwise already-trusted authority, with the correct name. A staff passphrase is a different WLAN's credential. It does not replace a web certificate, and the guests are already at the portal. Hiding the guest SSID does not mark a certificate trusted. Trust is a certificate-store decision on the device, not a beacon flag. The beacon interval does not renew certificates. A faster beacon leaves the untrusted certificate exactly as it is. Exam caveat: the certificate name has to match the name in the redirect. A trusted authority with the wrong name still warns. Operational check: open the portal in a clean guest browser, confirm the warning is gone, and confirm the certificate name matches the portal address.