So the phrasing here is odd to me, but they are correct in their assessment. Generally you see the requirement as a root CA cert that is then imported into the trusted cert repository on all your endpoints. I've never heard it phrased as "install[ing] the public key" on all endpoints. Other than that, they are correct.
The Windows boxes, presuming they're all on a domain (or series of domains) should be the easiest to do - you can push that root cert out via GPO. With the Macs, I'm guessing things like Casper could push the relevant root cert out to the various boxes and/or iDevices. I've never used Chromebooks, so I have no idea how one does that, though I know Google has a suite of enterprise tools for general management - I'd guess there was something that could be done there. What the iBoss device is doing is looking at the initial connection, minting a new cert on the fly for whatever.site.com, then presenting that back to the client browser. Sometimes that cert is cached for future use, other times it's created and destroyed upon termination of the connection. But that minting of the certs on the fly is what you need a root CA certificate. In order for your browser to accept this, you have to have that root CA cert accepted by the endpoints. Your *.nsd.org cert would work to intercept traffic for all *.nsd.org sites, but would be useless for, say, www.driftpeasant.org. I have no idea how you've gotten this far using *.nsd.org - from everything I know, that should fail hard pretty much immediately. On Thu, Oct 9, 2014 at 6: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/
