Subscribe
When a new SecureNAT computer connects to an HTTPS web page the Captive portal process "does not work". Either the HTTPS site opens without Captivate, or the connection is denied.
More Information
When an HTTPS URL is entered into the browser, it creates an encrypted connection to the remote web server. Under normal circumstances, there is no way for Captivate (or anything else) to break into that encryption and issue a redirect. This behavior comes from the security design of HTTPS, and it is not possible to change this behavior. You have three basic options for how to proceed:
- Redirect HTTPS requests into the Captivate process: To do this, you need to use forward HTTPS inspection. In ISA this can be done with our ClearTunnel filter. In TMG this ability is built-in. Using inspection will make ALL certificates for all sites that the user visits be signed by the web proxy, so SecureNAT clients will always get security warnings for each site. This is, again, by design of HTTPS and SSL and not something you can change. (Note however, if the client machines are managed domain members, you can push the certificate root's public key to them via group policy).
- Block HTTPS connections before Captivate: In the properties of the HTTPS protocol on TMG/ISA, select the checkbox for the Captivate Application Filter. This will cause all HTTPS connections to be blocked (with errors) until the user tries to visit an HTTP page, and gets redirected through the Captivate process. Please note you must not hook the Captivate app filter to the HTTP protocol, only HTTPS.
- Allow HTTPS connections before Captivate: Unhook the Captivate application filter from the HTTPS protocol. This would allow free access to HTTPS sites without blocking at all, regardless of whether the Captivate process has occurred.
Please understand, these three options are the only possible solutions, based on the cryptographic design of SSL and HTTPS. There is no way we, or anyone, could design a zero-client system to get around these limitations.
