- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Network World - 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.
We have always been told that SSL certificates are only secure if they are issued and signed by a trusted signing authority, and that we should never use a self-signed certificate except for limited internal use and for testing purposes. We would be crazy to implement a self-signed certificate in a production environment.
Is this really true, or simply the Kool-Aid of an industry driven by dreams of revenue?
TECH ARGUMENT: SSL certificate authorities vs. ???
Consider this: If you know the person or entity you are getting your security keys from, would you trust them more? More often than not the answer is yes, or at least probably. Now, if you were the one issuing your own certificates, would you trust yourself more than someone you know well but not intimately? How about someone you don't know at all? I hope the answer is yes!
Given this, how could self-signed certificates be suspect if they are implemented properly and securely?
Self-signed certificates do pose a higher risk if not properly implemented, but, in my opinion, offer the same or more security if implemented properly.
Certificates that are issued by a "trusted" certificate authority (CA) are considered trusted because of several criteria. First, they pay the browser suppliers (e.g. Microsoft for inclusion in Internet Explorer) to validate certificates that they sign. What this means is if you have a certificate signed by one of these "trusted" CAs your browser will not balk at the website using it, so long as the information contained within the certificate is accurate and matches the site that you are visiting and that the certificate is installed to protect. [Also see: "With SSL, who can you really trust?"]
Often individuals and organizations utilize SSL certificates to protect information that is contained on a website or in Web-based applications. These applications are targeted at both internal (corporate LAN based) and external (Internet facing) users, depending on the nature of the site the certificate was created to protect.
If you decide to go the route of using self-signed certificates, the first thing you must do is make sure your infrastructure itself is secure. If you cannot protect your internal CA server, then yes, you are no better off than with anyone or anything else. It is like building a house with a weak foundation. If your foundation is not sound the house will be compromised and could collapse at any time.
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.