Please check this blog page for some more background.
In a nutshell, there are two parts here:
1: The redirect.
2: The splash page/captive portal page itself.
The second one is easy: get a public trusted SSL server certificate. I'd believe most of the CAs out there supply certificates that are trusted by most clients. I have not seen big differences myself, but there are tables of which CA is in which OS and browser.
Then the redirect. This works by intercepting a client HTTP request and returning an HTTP and/or HTML redirect code, which redirects to your splash/portal page which itself is HTTPS, which is all fine.
Now we have 5 options for the redirect being triggered:
1: The captive portal is delivered to the client via DHCP (RFC7710), which has a lack of support in clients (as far as I know), so isn't a reliable option.
2: The operating system (Windows, OSX, Android, IOS) will try to do an HTTP request in the background just after the user connects to the (wireless) network. As this is unencrypted HTTP, the AP/controller can intercept and 'spoof' the redirect on behalf of the server that the OS tries to reach. The device detects the redirect and pops up the captive portal. This option is mostly used and it can be recognized as there is some kind of automatic pop up on the device. The user does not need to open the browser or take action other than connect to the wifi.
3: If the OS does not detect the captive portal, a user can open a browser and connect to an HTTP site. Controller/AP can do the redirect in the browser. This option becomes less and less relevant as users don't go anymore to HTTP sites. They have their start pages to Google, Facebook or other HTTPS sites (see next points).
4: If the OS does not detect the captive portal, a user can open a browser and connect to an HTTPS site. As the Controller/AP does not have access to the private key belonging to the certificate for the site that the user tries to open, it has to either block the request or present an untrusted certificate. The user would have to ignore the certificate warning, which users should not be taught. My recommendation is to either allow through without redirect or reject HTTPS traffic in the captive portal. As allowing through these days basically means full internet access without logging in, it might not be a viable option.
5: If in case 4 the user connects to an HTTPS site with HSTS enabled, there won't be an option for the end-user to ignore the warning and follow the redirect. This confirms the recommendation from point 4: reject/block or allow HTTPS traffic; do not redirect.
Hope this clarifies some of your questions on this topic. From the above, you may conclude that captive portals are becoming problematic as only the OS captive portal detection is a viable option. Redirecting HTTPS traffic is not practically possible, and as most operating systems have captive portal detection, it should not be needed either.