The Risks In Wildcard Certificates

 
 
By Larry Seltzer  |  Posted 2008-10-11 Email Print this article Print
 
 
 
 
 
 
 

They may not be real-world problems, but wildcard certificates have some definite theoretical problems. But they can be so much cheaper that users will buy them anyway.

The imperative to use SSL, for web authentication and encryption or VPNs, is reasonably universal. Competition has driven prices of certificates down over the years to the point where you can get conventional SSL certificates from reputable vendors for well under $100 per year.

Another product gaining popularity due to competition is the wildcard certificate. A conventional certificate works on a single domain, e.g. www.foo.com. A wildcard certificate protects all subdomains of a domain subject to the use of wildcard characters in the name. So a wildcard certificate for *.foo.com protects www.foo.com, bar.foo.com, mail.foo.com, chasephish.foo.com, and so on.

I have received many notes from vendors about them, both as press and as a prospective customer. Most CAs (certificate authorities) clearly see them as a way to grow markets. If you've got a lot of domains you can save a lot of money with a wildcard certificate relative to buying individual certificates for them, but not from all vendors. VeriSign, the 800 lb. gorilla in the CA room, prices wildcard certs by the domain being protected, so that they don't save much, if any money outright.

There is still a potential to save in convenience of administration with a wildcard certificate. But there are real downsides to wildcard certificates. When things go wrong the convenience may evaporate quickly. The VeriSign site lists their take on the disadvantages of wildcard certs:

  • Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
  • Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.
  • Compatibility: Wildcard certificates may not work seamlessly with older server-client configurations.
  • Protection: VeriSign Wildcard SSL Certificates are not protected by NetSure extended warranty.
I hope it doesn't need to be said that VeriSign, as the dominant market player, has an interest in prices remaining high, so take their advice on wildcards in that light. The last point is VeriSign saying that wildcards get a lesser level of service from them, so that's not a problem inherent in the technology, but the other 3 points are reasonable generally. It's true that a compromised wildcard certificate is a bigger problem than a certificate for a single domain. It's probably also a bigger target. How big a problem is this? Using the same certificate means that every host in the domain is using the same key pairs. This means that if the keys are compromised for one host, the entire domain is compromised. At the same time, the larger number of systems relying on those key pairs multiplies the number of potential weaknesses through which a compromise may be found. Fundamentally, this makes wildcard certificates a weaker, less trustworthy solution than individual certificates.

What VeriSign says about management is also true, but whether it's a real burden to replace a wildcard certificate depends on the management system you're using. It may be some work, it may not be. It's also true that if you need to revoke a certificate your CA needs to move fast and when you need them. I'm not sure all CAs, even reputable ones, perform the same in this regard.

As for the compatibility issue, it seems there was something there, but as VeriSign says, it's a problem with older software. This page details some compatibility problems with older client software and wildcard certificates. You don't see a lot of current versions in there.

I suspect there isn't a lot of real world data on whether wildcard certificates are more of a security and management problem than per-domain certificates. It may not amount to much. I think there's probably something there in the aggregate.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack

 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel