Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

BLOG: Are self-signed SSL certificates as insecure as they say?

Cory Flynn, CEO and founder of Firewall Experts | Feb. 16, 2012
Given the recent problems with SSL certificates provided by third-party companies, one has to wonder why we place all this trust in these vendors. We allow them to process and produce "trusted" certificates for our websites, but in the end even Google, Microsoft and state and federal governments are falling victim to fraud.

Next, never co-locate (or share) your certificate server with any other functions. It will be just as bad as leaving the systems out in the wild.

You must also protect your servers that will be issuing SSL certificates so you don't become just another statistic. Proper implementation of your CA root certificate that is used to sign all SSL certificates in your environment is paramount in order to maintain a secure SSL implementation. If the bad guys get your CA root private certificate, your implementation is useless.

So, make sure you have your server located in the most secure part of your offices/data center. Location, location, location is critical. It is recommended you have it in a secured area of the building monitored by video surveillance and housed in a locking server cabinet. Least privilege access to this location should be implemented. It is also not a bad idea to actually shut down this server when not in use.

Now comes the hardest part: proper implementation on the client side. You need to deploy your public root certificate to all users that will be connecting to your site so they do not receive the message that the certificate is not trusted. This can be done either manually in most browsers, or automatically in some.

To make certificates you issue trusted you need to deploy your root server's public certificates into workstation browsers that will be accessing your secured websites. This is so that when users attempt to access websites that are using SSL certificates signed by your root CA, they are now considered trusted in your Web browser just like a "signed trusted certificate."

Big-name SSL vendors might like you to think that performing this is difficult. While the process is tedious, it is not brain surgery. It can be done, for instance, in Internet Explorer via a Group Policy Object in Active Directory. Firefox and Safari systems require more work, but it can be achieved and, once it is done it is done, you only need to plan this type of update every three to five years. This would be a small price to pay for control of your security.

Yes, the administrative overhead of maintaining your own CA server and your own SSL certificates is higher on your end, but think of it in a different way: This model allows you to be in full control of your environment. You can proactively revoke compromised or suspect certificates. You can reissue new certificates or key pairs at your leisure and discretion. For larger environments, the benefits certainly seem to outweigh the take-backs.

Ultimately you need to map out what your organization or individual needs are and what is expected from your SSL implementation. Outline that need for security in a formal SSL and cryptography plan for the infrastructure. Ensure all action items are in line with your objectives and make sure that you accept any risks (identified through a formal risk assessment) that arise with the options you choose (this would be ease of use versus overall security and control for instance).

 

Previous Page  1  2  3  Next Page 

Sign up for MIS Asia eNewsletters.