In order to return an intelligible page to the client, Enable SSL Client Context has to be invoked. It's possible to use Enable SSL Client Context without performing certificate verification or content inspection.
If the problem with SSL scanner is limited to the fact that ultimately the connection between the client and the server needs to be unaltered, you can probably invoke Enable Client Context prior to your welcome page rule. This may necessitate moving the Set Client Context rule up higher in the overall rule set. Another alternative would be to wedge in the welcome page right after the Set Client Context rule.
Thank you, yes, that gets me closer.
However, when enabling Client Context, I need to specify the CA to use, right?
Using either "Enable SSL Client Context without CA" or "with CA" both result in SEC_ERROR_UNKNOWN_ISSUER in Firefox.
Client can add an exception and is then presented with the Welcome Page, true, but that's no fix, right?
Sounds like I would need to have a cert signed by one of the root CA's in order for this to work. No?
Time for me to review my TLS/SSL 101 basics?
2 of 2 people found this helpful
You do indeed need a Certificate authority for the client context rule, you should be using the "with CA" event.
"With CA" means we use the certificate given to dynamically issue certificates. "Without CA" means we present the given certificate (static).
You will not be able to get a certificate (authority cert) from a public authority as that's akin to asking the government if you can print your own money . If you have a private authority you can ask that they create a subordinate certificate authority (you must explicitly ask for a sub CA, not a traditional web server certificate).
The guide here: Best Practices: Giving your SSL Client some Context gives an overview of what client context does for you.
Hi, Jon, thank you -
yes, exactly, I understand. Which brings me back to my question:
since first client request is for https://,
since we have no opportunity to install a trusted cert to the client,
since we have no opportunity and do not wish to instruct the client on how to install the cert themselves,
since Welcome Page is handled by MWG via a 302 redirect, which has to be done inside the SSL/TLS tunnel to be successful,
we therefore have no opportunity to present the client with any browser readable/renderable content that we could control (acceptable use policy, welcome page, hours of operation, etc), correct?
1 of 1 people found this helpful
Given the circumstances mentioned above that would be correct, however you could look at redirecting the internet connectivity test (sent by the client -- this varies by device).
Every machine should send a request for a special URL (Appendix K: Network Connectivity Status Indicator and Resulting Internet Communication - example for Windows) if that request fails, your machine or device will bring you to the welcome page (like when you need to sign-in for wifi on mobile).
I havent done this myself, but it might be possible.
hmm. interesting. I tought I might end up having to workaround at an earlier stage, perhaps during IP provisioning, but your idea might work _and_ let me do it at MWG...
know of any managed lists I can subscribe to for "special connection testing" URIs for all the various OSes?
I'm interested in this aswell as i have a similar/same situation. For me we have people bringing in BTOD devices that we want to get to auth at an auth page. Currently we use the built in CA in WGW so if users have a homepage set to https our redirect to the auth page fails with some browsers ( Chome generally ). As above we have no way before this point to install a certificate etc. My last resort is to dump the required cert on an external HTTP page and allow our users unauthenticated access to that site only until they install the cert and Auth, we would have to provide information around this to users but it would be a usable workaround.
i have to say, i have not read the whole thread in detail. Regarding the Firefox SSL message. If firefox does not show the SSL page you have to use a certificate with a higher hash algorithm. Newer versions of Firefox change some things in the security, therefore you need a new certificate on MWG.
We had the same problem in our company when installing Firefox newer than version 38.
Hope this helps,
1 of 1 people found this helpful
I just had a play with the Microsoft NCSI stuff and was able to get a windows machine using chrome ( as it commonly complains about sketchy certs ) to redirect to our auth page without having to have our CA cert on the device. I placed this rule above our SSL scanner section. Its a dirty test rule so don't pay it much mind, but by redirecting on the url/domain in the image when i connected that test client to wifi it automatically opened chrome and redirected to our auth page. Without this when you open chrome you are prompted with a cert error that you then have to bypass ( some browsers though don't let you ). Troja has touched on a point that i need to sort internally with changing our WGW CA to issue SHA256 certs not SHA-1 as currently even clients with our cert installed barf at SHA-1 stuff occasionally now too. I did only test this on a single device so will do more testing soon. If all goes well Gunnars you should be able to create a custom block page in WGW and do the same for a welcome page. This is only for Windows machines but i think apple has a similar thing using http://apple.com/library/test/success.html