I recently read this question, which makes me wonder a follow up question: how is this captive portal likely trying to redirect the user? A highly voted comment does say that it's doing it wrong, after all.
So if one had a legitimate and well intended captive portal, how should it be redirecting users to the portal while keeping in mind user's security and convenience? It's obviously bad for both security and convenience if users are getting a certificate mismatch like in the linked question.
Technically a captive portal is always a man-in-the-middle attack. Therefore, all techniques against MitM will and should warn about them, giving the user power to decide whether to trust or not. Some browsers do have captive portal detection, in general temporarily allowing the redirection without showing any page with the original domain.
Contemporary security needs make transparent implementation of captive portals challenging. Thankfully, web browser and OS developers realize the importance of reporting the existence of this intermediate status between being connected to the Internet or not, this way reducing failure cases to a minimum.
From this perspective, redirecting to a separate captive portal login page with a properly signed and matching certificate would be less evil than showing the login page directly with any domain.
Do we have other options?
We could perform the redirect only on plain HTTP to avoid the certificate mismatch error. It would still be a MitM, but on a protocol that wasn't designed to detect it. This would have worked perfectly fine before HTTP Strict Transport Security (HSTS) against our protocol downgrade attack, which this kind of captive portal would be.
No redirection at all. Simply block all traffic before the user has manually opened the login page URL and logged in. Security maximized, at the expense of convenience. Now, you have to inform your users about this arrangement, which usually means need for extra support. Even if you tell your users with pictures that they need to type this address into address bar, some of them still tries to search the address from Google.
Abandon open WiFi and use another authentication methods. No need for captive portal nor login page. Severe need for support. WPA2 enterprise would be technically ideal as you don't need a single pre-shared key, but it's less known to the target group (people using open access WiFi).
At the same time these are the very reason why captive portals still exists. My idea of a suitable replacement for captive portals would be a standardized plain HTTP URL that browsers would try to access when ever something blocking the connection is detected. That page would then perform the redirect to the login page with HTTPS and a proper certificate, and the browser should detect anything else as an attack. But this is just my dream, far from reality. Captive portals will exist as long as they work in practice.
Unfortunately, there is no perfect solution here, given the fact that the very purpose of TLS is to protect against this kind of attack. But I think the best possible way to go is this:
The 511 status code indicates that the client needs to authenticate to gain network access.
[...]
The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.
