Follow Us

We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

Self-signed SSL certificates can be secure

The problem with trusting vendors over your own authority

Article comments

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?

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.

Often individuals and organisations utilise 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 colocate your certificate server with any other function; that would 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 centre. 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's 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 organisation 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).

We cannot, after all, as individuals or companies, cry foul because we chose to allow a stranger to hold the CA keys only to find out that stranger turned out to be lax and a party to thieves.


Share:

More from Techworld

More relevant IT news

Comments




Send to a friend

Email this article to a friend or colleague:

PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.

Techworld White Papers

Choose – and Choose Wisely – the Right MSP for Your SMB

End users need a technology partner that provides transparency, enables productivity, delivers...

Download Whitepaper

10 Effective Habits of Indispensable IT Departments

It’s no secret that responsibilities are growing while budgets continue to shrink. Download this...

Download Whitepaper

Gartner Magic Quadrant for Enterprise Information Archiving

Enterprise information archiving is contributing to organisational needs for e-discovery and...

Download Whitepaper

Advancing the state of virtualised backups

Dell Software’s vRanger is a veteran of the virtualisation specific backup market. It was the...

Download Whitepaper

Techworld UK - Technology - Business

Innovation, productivity, agility and profit

Watch this on demand webinar which explores IT innovation, managed print services and business agility.

Techworld Mobile Site

Access Techworld's content on the move

Get the latest news, product reviews and downloads on your mobile device with Techworld's mobile site.

Find out more...

From Wow to How : Making mobile and cloud work for you

On demand Biztech Briefing - Learn how to effectively deliver mobile work styles and cloud services together.

Watch now...

Site Map

* *