To filter HTTPS traffic in this way, you *do* in fact need to "pose as Google" using a self-signed cert. You're essentially performing a MitM attack against your own users, in that scenario - and yes, think of the damage you could do. If you don't want to do that, then you can't filter the HTTPS traffic.
On Thu, Oct 9, 2014 at 7:46 PM, Ski Kacoroski <[email protected]> wrote: > Hi, > > I need someone with more certiticate-fu than I have. I have an iBoss web > filtering device that sits in between our internal users and the internet. > We are trying to set it up to also filter https web pages which means it > has to decrypt the connection to see what is going on. They are claiming > that we have to use a self-signed cert on their device instead of our > wildcard *.nsd.org cert and then install the public key on all the > browsers of our internal machines which, as you can imagine, is not > something we want to do or maintain. I have 6500+ macs, 3000 chromebooks, > 2000 ipads, 1000 windows, and several hundred other things such as kindles, > etc. In addition, several of these have multiple browsers. > > I appreciate any comments or ideas why we cannot get our wildcard cert to > work (it works with erverything else except for an old Oracle application > server where I had to get a machine specific cert). > > Their description is: > -------------------------------- > > * The certificate needed to do the decryption must be trusted by the > browser to sign ALL domains. > * GoDaddy and other Certificate Authorities (CA) will not sign a > certificate for use with domains other than your own. So… The certificate > must be self-signed with no verification path back to a trusted CA. > * The *.nsd.org certificate you have will work to access the iboss UI, > block or login pages. > > Follow up email states: > The first 2 bullet points from yesterday are important to understand. > There is no possibility of getting a CA certificate from anyone that is > trusted by the browsers. As far as we have seen it takes a CA cert to be > fully functional for intercepting HTTPS traffic and re-sign so that the > browser will accept it. This means using a self-signed cert. To stress the > point, imagine what damage you could do with a certificate that allowed you > to pose as Google without the browser alerting the user. > > I can’t answer why we have had the limited success with decrypting using > the *.nsd.org or how far we can push it. In a couple cases we were able > to get everything working unless Chrome was used. In another case IE seemed > to be the biggest problem. They each perform validity checks of their own > design. Technically, the cert you have should not be accepted to sign > anything. That is not a feature of the cert (CA:FALSE). > -------------------------------- > > cheers, > > ski > > > -- > "When we try to pick out anything by itself, we find it > connected to the entire universe" John Muir > > Chris "Ski" Kacoroski, [email protected], 206-501-9803 > or ski98033 on most IM services > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
