Skip navigation

Self-signed Certificates Lead to Many Problems

Those who advocate the use of Office 365 instead of on-premises servers for small businesses were provided with some additional support for their stance when Australian researcher Peter Hannay reported how Android or iOS devices might fall victim to a “man in the middle” attack and end up wiping device contents. The root cause of the problem is the use of self-signed certificates, a habit supported by Exchange, but only really intended for test systems whose connections are not exposed to the Internet. If you're not sure how certificates work at this point, check out Jan De Clercq's article on the topic. And if you want details of the problem exposed in this instance, you can read all about it on Paul Robichaux's blog.

Best practice for production systems is to secure all certificate-enabled communications (like SSL) with a certificate purchased from a reputable commercial vendor such as Twaite or Verisign. Windows Phone clients appear to be better protected, but you never know with self-signed anything.

Small businesses don’t tend to operate sophisticated IT shops. In this environment, it’s no surprise when short-cuts are taken or costs that appear optional are eliminated. Certificates have a history of being difficult to manage for Exchange, which is the reason why the developers have spent so much effort to improve the process of creating certificate requests, importing certificates, and associating them with services in recent versions of Exchange. Certainly, the old adage that an Exchange administrator had to be somewhat of a certificate guru if they wanted to establish external connectivity was true in Exchange 2003 and Exchange 2007. 

Certificate management is much easier in Exchange 2010 as new wizards and better processes provide the automation to make certificate handling much easier. Of course, this effort isn’t solely for the benefit of Microsoft’s customers. Many support problems with certificates clogged Microsoft’s support organization and these problems tended to be pernickety and hard to solve, or in another word, costly to resolve all the support calls. Microsoft has a long history of addressing problems in their products that generate high support costs – simplifying storage in Exchange is another example.

The advent of Office 365 is another reason why Microsoft had to make certificate handling easier in Exchange. Hybrid organizations simply cannot function properly without well-secured connections between the on-premises and cloud components. This is also true for federated organizations.

Getting back to the problem in hand, self-signed certificates are cheap because they are generated by a company for their own use rather than being purchased from a commercial provider. Costs for commercial certificates vary from vendor to vendor. Other factors such as the number of names covered by the certificates and support also come into play before arriving at the final charge. But even the most expensive vendor will only charge a few hundred dollars for their services and often the cost is less. Even so, the cost of certificates is sometimes viewed as a “nice to have” by small companies rather than an essential factor in securing external communications. It seems like an easy decision to eliminate the cost, especially when a self-signed certificate “will do.”  

The problem has grown recently. A larger proportion of small companies use Exchange 2007 or Exchange 2010, both of which make external communications easier than Exchange 2003 (the issue is more obvious in Exchange 2007). And then there’s the huge growth in smartphone usage with the resulting demand from users to be able to connect to their email, calendar, and contacts while out and about. ActiveSync makes smartphone connectivity easy and it’s supported by all the major smartphone manufacturers, including those who create Android devices and Apple.

ActiveSync has become the de facto connectivity protocol for smartphones. At least, it would be if all of the vendors implemented ActiveSync completely for their devices. For now, ActiveSync is a kind of loose de facto standard. All of the “standard” features like those necessary to fetch and send messages or synchronize calendars tend to be implemented while the more advanced features that round out ActiveSync by providing management functionality are not. Exchange 2010 attempted to address part of the issue by providing much better server-side management for ActiveSync devices but it’s still not a good situation to be in when you can’t depend on a consistent implementation of the protocol everywhere. In any case, ActiveSync is pervasive and everyone uses it to connect to Exchange (on-premises and cloud), including across unsecured connections that use self-signed certificates.

But now it’s been shown just how silly it is to save a few pennies on a certificate to create the potential for compromise and even some malicious device wiping. All of which goes to prove that running an email server is a more complex business today than it was when Exchange 2003 was king of the heap, if only because users expect to be able to connect with so many types of devices.

To me, the solution is pretty simple. Small companies (up to 100 users for instance) should give Microsoft all the headaches of maintaining service levels, security, server maintenance, and so on by replacing on-premises Exchange servers with Office 365. Although there will always be exceptions to the rule, I simply cannot see how the vast bulk of small companies can continue with the fool’s errand of running their own email server, unless of course they function in a part of the world that doesn’t have sufficient network capability to connect reliably to an Office 365 datacenter. Believe me, the Microsoft people have more technical capability and resources than any small company, so they’re more likely to get the detailed stuff right.

On the other hand, if you work for a larger company that continues to use self-signed certificates as the basis for non-existent security, then you should be ashamed of the company’s willingness to expose itself to risk. It really is that simple.

Follow Tony @12Knocksinna

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish