Why do I see certificate warnings on hotspot logins?
Q: We recently decided to install SSL certificates on all of our hotspot routers.
I’m sorry that the answer is not short ;-)
What you are seeing is failure of the certificate validation. Keep in mind that https is a three party process: client, server and certificate authority. When a client makes an initial request to the ssl server, the server replies (as part of the https setup handshake process) with the certificate public encryption key. Embedded in the key is the details of the certificate issuer (certificate ‘signer’) – the client then checks with that certificate issuer to make sure that the public key provided by the server matches what the signer says is the correct key for that domain/hostname. This is how we can be confident that when we visit some http service that it is NOT some third party intercepting our requests and masquerading as that third party.
The problem when doing this behind a captive portal is that the captive portal will usually block access to the certificate authority validation server and/or the revocation server. Therefore, the client is not able to ‘validate’ the certificate. The client/enduser can usually ignore the warning and continue with the request and maintain an encrypted session, but doing so also requires that they must risk the possibility that the remote web site is not who it claims to be.
OK, so you probably already know that, and since you seem to have got to the stage that your ssl login page works OK, you may have already added the OVA/CRL servers for your certificate issuer into the captive portal. If you have NOT done that, then the only reason that you do not see the warning on those other browsers is that you have already cached the web server certificate (for secure.myport.com.au) in the maxOS certificate cache – careful! Other customers who have not previously accessed your web site may still see the certificate warning when accessing the captive portal unless you add the CRL/OVA servers to the walled garden list)
So to answer your question, the reason that you see the waring when you use firefox and not with the other browser is because it is not access to YOUR web site that is spawning the error, but in fact access to the google service that is causing the problem:
It is possible that the error is because the client is not able to validate the google certificate (unless you have walled garden exceptions for the google certificate signer services) but there is another factor at play here too that is also likely to cause a problem.
Consider what happens when you try to access an ssl web site from inside a captive portal. What about when your default home page is a http location (e.g. https://my.google.com) ? If you connect to the wifi, then open your web browser, it will issue a web request to https://my.google.com – BUT your captive portal will intercept that request, and reply ‘on behalf’ of my.google.com with a 302 redirect to the hotspot login page. But that initial request is https protocol, and the only way that the hotspot can issue a reply is to go through the whole ssl setup process, INCLUDING proposal of the public key. However, the public key will NEVER match what the certificate authority says is the correct key for my.google.com (unless you ask google to kindly give you their private key so that your hotspot can decrypt encoded requests! ;-) and so that kind of request will ALWAYS throw a certificate warning message.
Since the firefox browser has a home page that is hosted locally;
there is no need for any ssl – but that form submits to https://www.google.com/?..etc.. and there lies your certificate problem.
Unfortunately, there is NOTHING that you can do to prevent this from occurring (other than what I hqave suggested above – which, arguably, will also never happen! ;-)
Hope it all makes sense!