On Message with Ben Gross
Purchasing SSL Certificates
Secure Socket Layer (SSL) is a well-established and tested mechanism to secure traffic on the Internet and has near ubiquitous support in modern browsers and email clients. SSL is also commonly used to secure SIP VoIP phones, Jabber/XMPP instant messenger sessions, Subversion revision control repositories, as well as to create SSL-based VPNs. While the Transport Layer Security (TLS) specification has technically superseded SSL, publications typically still refer to SSL.
Netcraft reported that in June of 2006 roughly one quarter of the approximately 2 million sites that were able to respond to an SSL request had a valid SSL certificate. Netcraft's November 2007 report found 149,784,002 servers. Given that nearly every consumer has an SSL enabled browser and email client, why is server side adoption of SSL so low? An obvious reason is the cost, but the more probable reason is the complexity of acquiring and integrating SSL certificates that limits adoption on the server side.
While the topic of usability of acquiring server side SSL certificates may seem arcane, it remains important, as SSL is currently the only widespread mechanism to secure consumer to business transactions at scale on the Internet. There is substantial discussion of the practical efficacy of SSL in light of phishing attacks. Extended Validation certificates are an attempt to improve the situation, in addition to consumer education to not simply click away every error warning. However, until a better mechanism comes along, we are stuck with SSL, as it is what gives most consumers basic protections for Internet commerce. SSL is also one of the most common mechanisms used to secure email. For example, the SMTP Submission protocol requires both authentication and a SSL secured session.
SSL is designed to be part of a Public Key Infrastructure (PKI). Both client and server applications must include support for SSL for the connection to be secured. An SSL server certificate is required at a minimum. Certificates are issued (signed) by a Certificate Authority (CA). It is possible to set up a private certificate authority and produce a "self signed certificate." This is often done for personal use or development purposes. Self signed certificates are not verifiable through the public PKI chain and will produce browser warning messages unless the user explicitly loads the credentials for the private certificate authority into each browser.
Purchase Process
For many organizations, SSL certificates are moderately expensive, complicated to purchase, and even more complicated to install. I recently purchased a renewal for an SSL certificate and was disappointed that the process has not become substantially more streamlined than five years ago. Going through the process, it is easy to see why so few sites, especially smaller ones, use SSL certificates. On a related note, acquiring a client side S/MIME certificate, which is needed to encrypt or sign email or Adobe Acrobat documents, is similarly complicated. Neither process instills confidence that our communication channels will likely be any more secure a year from now. Clearly, in the usability of the purchasing process there is great room for improvement.
For example, I recently renewed a GeoTrust QuickSSL Premium certificate for my own use. GeoTrust purchased Equifax secure in 2001. Verisign purchased Thawte in 2003 and then GeoTrust in 2006. Now Verisign controls the majority of the SSL certificate market, which includes GeoTrust certificates that are more economical than Verisign-branded certificates. The GeoTrust credentials are in nearly every modern browser. The Comodo Group and Go Daddy are the only major competitors but neither have quite the browser acceptance of the Verisign family.
My recent GeoTrust experience confirms my point on purchasing complexity. The GeoTrust Website states that one of the benefits of a QuickSSL Premium certificate over a plain QuickSSL certificate is "99 percent, plus popular mobile devices and smartphones". This presents a problem because GeoTrust never defines what the 99 percent means. While there are many GeoTrust resellers, they were of little help since most simply copy their text directly from the GeoTrust site. After substantial research to determine the difference between the two types of certificates, the only explanation I could find was in a knowledge base article on the GeoTrust site. There is no way to directly link to this article and I could not find a single other reference explaining the distinction. The knowledge base article said:
"Where can I find a list of GeoTrust's root certificates? A list of GeoTrust's root certificates can be found at http://www.geotrust.com/resources/root_certificates/index.asp. The root that is used to issue our QuickSSL Premium, TrueBusinessID, Power Server ID, and Wildcard certificates is the root labeled "Equifax Secure Certificate Authority" (Root 1). The root that is used to issue our QuickSSL certificates is the root labelled "Equifax Secure Global eBusiness CA-1" (Root 5)."
This turns out to be a key point. In order for the above information to be useful, you have to know if your browser or microbrowser has the CA in its list of trusted CAs (also known as a CA "bundle"). GeoTrust provides only an outdated list of support browsers and (for the Premium version) microbrowsers. The most recent microbrowser listed in the support documents is Windows Mobile 2003. An IMAP client running on a Symbian Series 60 would not recognize the plain QuickSSL certificate, unless the certificate authority was loaded into the phone by hand. This is a process that most consumers will never attempt, but could be handled in the provisioning process.
Improvement Needed
Because there is effectively no standard CA bundle for applications, operating systems, or mobile devices, each vendor has its own bundle of "trusted" certificates. This means, every application that employs SSL may use a different bundle, even if they are on the same machine. It is difficult to determine what CA's are supported without extracting the CA bundle and analyzing it. This substantially complicates the problem for businesses that wish to determine which certificate may meet the needs of their users.
In general the information on certificates is so poor that it is routinely difficult to make a business decision on which certificate to purchase in order to meet customer needs. I suspect that many companies have their own tables of browser compatibility for various certificates. It's far worse for the mobile market.
It seems like there should be a market for automatic certificate installation in common machine configurations. Both Microsoft and Apple have made strides with better GUI administration tools for SSL certificates. A number of web hosting services sell SSL certificates with installation for users who pay for the certificate and a static IP address. Another improvement on the horizon is RFC 3546—the Server Name Indication (SNI) extension for TLS. This will effectively allow namebased virtual hosting to use SSL similar to the namebased virtual hosts in HTTP 1.1. One major benefit is that this will allow multiple SSL enabled hosts on the same IP address. These are welcome improvements, but we still have a long way to go. BG/TMP