title: Are certificates useful for intranet SSL?
body: <p>I've been tasked with development of an intranet interface for command line software, and now I'm researching security options. Our command line application is finished, but I haven't started writing the web interface. I don't know exactly what the security requirements are for potential customers, although I believe <code>ssh</code> is generally acceptable for the command line interface. With this in mind, I'm asking for help developing a menu of choices with their associated pros/cons. Some day, we may consider releasing our web interface to the internet, so I'm willing to consider more security than currently necessary if it's easy and/or free.</p>
  
  <p>I've been doing a lot of reading, and my tentative conclusion is that SSL security with no certificate is the best approach, not because less security is unacceptable, but because SSL is the standard and because it doesn't appear to be difficult to set up. I, a security non-expert, wouldn't need to explain why less security is acceptable to security non-experts. I could upgrade my application to use a certificate in the future if necessary.</p>
  
  <p>Here's a list of SSL related security choices, sorted by my perception of security level with my comments. What level of protection do I need?</p>
  
  <ol>
  <li><p><strong>No SSL.</strong> This might be acceptable if our customers aren't worried about their employees seeing/changing each others' data. Their employees might want to share results with each other anyway, and I could use IP based access control and/or passwords for security.</p></li>
  <li><p><strong>Do SSL with no certificate.</strong> This encrypts the communication, which at least protects the data from being read by unauthorized employees. Using a password, this is the same level of security as <code>ssh</code> on the command line, right? I don't need to worry about man-in-the-middle attacks in an intranet, right? A con for this approach would be if there were loads of browser warning messages.</p></li>
  <li><p><strong>Do SSL with a self-signed certificate.</strong> What does this give me that no certificate gives me? If the DNS can be changed inappropriately, then the customer then my application is the least of their concerns. Worded another way, if the DNS can change, then I think <code>ssh</code> would be vulnerable too.</p></li>
  <li><p><strong>Do SSL with a local Certificate Authority.</strong> OpenSSL lets me make my own Certificate Authority. What does this give me that a self-signed certificate does not? I'm assuming that on a LAN, it's less important for the server to be verified. </p></li>
  <li><p><strong>Do SSL with an external Certificate Authority.</strong> Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.</p></li>
  </ol>
  
  <p>For reference, this page might be useful for comparing certificates:</p>
  
  <p><a href="http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts">http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts</a></p>
  
  <p>[update]</p>
  
  <p><a href="http://www.networkworld.com/article/2457649/security0/new-ssl-server-rules-go-into-effect-nov-1.html">Here's</a> an article discussing the risks and rules of obtaining an internal certificate from a public CA.</p>