On Thu, Oct 25, 2012 at 11:15 PM, Craig Askings <span dir="ltr"><<a href="mailto:craig@askings.com.au" target="_blank">craig@askings.com.au</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">The normal trick for SSL is to make a new root ca + wildcard cert
    and forcibly install the root ca onto each PC via A/D or MDM for the
    iOS and Android devices. From there you just MitM with the wildcart
    cert installed on the UTM.<span class="HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br>Close but not quite.<br><br>They do involve a new root CA as you've mentioned, but not a wildcard cert.  Instead, they create dynamic certs for the sites being accessed, and then sign them with the root CA which the end-user trusts.<br>
<br>eg, user goes to <a href="https://www.facebook.com">https://www.facebook.com</a>.  The proxy creates a new certificate on-the-fly for the same hostname/CN/expiry/etc as the real <a href="http://www.facebook.com">www.facebook.com</a> cert, signs it using it's own root CA cert, and then uses that for the connection between the client and the proxy.  Presuming the client has the root CA in it's trusted list, this is completely transparent to the end user.<br>
<br>The problem here is getting the cert in the users browser.  In a controlled corporate environment this is relatively easy (standard build, MS GPO, etc).  In an uncontrolled environment, it's pretty much impossible.<br>
<br>  Scott<br></div></div>