Without trust, the entire Web of e-commerce would disintegrate. A 2005 report from Forrester Research showed that 84% of respondents don’t think retailers are adequately protecting customers online, and 24% didn’t make online purchases because of security concerns. People need to know that when they see the little lock symbol in their browser, their transactions are secured, and they’re conveying sensitive information to the intended party—not some nefarious criminal running a phishing scheme. Thus, there are PKI (public-key infrastructure) and CAs (certificate authorities), which issue digital certificates containing a public key and the owner’s identity.
• Digital certificate validity checking is essential in giving site visitors confidence in their transactions so they know they’re not at risk of falling prey to criminal schemes, such as phishing.
• The two primary forms of certificate checking are CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol). OCSP is commonly viewed as superior both in its more timely accuracy and its more efficient delivery architecture.
• Additional certificate systems, such as Extended Validation, can help enhance site visitor confidence.
Digital certificates, often called certs, can be used for many applications, but when a site visitor’s browser lands on one of your Web pages, that visitor needs to be positive that you’re the actual page owner. Certs provide this assurance. Once an SSL connection is established to the Web server, the connection is encrypted so eavesdroppers can’t snoop. The visitor’s browser will request the status of the digital certificate tied to your secure site. The public certificate gets served to the browser, but the status of that certificate still needs to be verified through the CA.
When a browser lands on a site with an Extended Verification SSL certificate, the Address bar will turn green and show the business’ name, the country in which the site is operating, and the CA’s name.
Why the need for verification? Certification Authority Comodo Group (www.comodo.com) likes to use the analogy of an employee driving a locked truck full of sensitive information. It takes two keys to open the truck, one public and one private. Anyone can get the public key, but the driver has the private key to get inside the truck. What happens if the driver leaves the company? He still has the key. The employer needs to "revoke" the key/certificate and render it invalid. Common practice says to only trust a commerce site showing a valid certificate.
Certification Revocation Lists
Certificates can expire once their issuance term is up, be revoked by the owner, or be revoked by the CA if the cert is being used for criminal activity. Traditionally, once a cert gets revoked, it gets added to something called a CRL (certificate revocation list) managed by the CA. When the user browses to the secure site, the CA pushes the CRL down to the client browser. There are two potential problems here. The first is list latency, meaning the time it takes for a revocation to be added to the CA’s CRL.
“So, my browser picks the CRL up and wants to find out if the certificate I’m using for a particular site is on the list,” explains Comodo CTO Robin Alden. “If it is, then it’s been revoked. If it’s not, well, it could be up to a day old, so perhaps it’s been revoked in the last 24 hours, and I don’t know about it. Some CA lists aren’t updated for a week.”
The other potential problem is list bloat, which especially threatens slower connections, such as dial-up or cellular.
“The CRLs have been of a manageable size, but in principle, it could become very unmanageable,” says Tim Callan, vice president of product marketing for leading CA VeriSign (www.verisign.com). “If 100,000 certificates were to get revoked, then you could wind up with a very large CRL, and the size of that could slow down browser performance and other problems.”
Bloat is somewhat contained by the fact that expired certs don’t get added to a CRL. Their expired date information already alerts browsers to a problem. Once a revoked cert passes expiration, it’s automatically removed from the CRL.
Online Certification Status Protocol
The solution for CRL’s shortcomings is OCSP (Online Certificate Status Protocol). Instead of just being a list that gets distributed to browsers, OCSP is a real-time record look-up infrastructure. When you’re in a browser that supports OCSP and look up a certificate, the cert carries a serial number. The browser knows to query the CA’s OCSP servers, which will deliver the status of that particular serial number. The number of revoked certs is irrelevant. Somebody could issue and revoke 10 million certs, and all that would happen is that the CA would need to add more servers to handle the traffic.
“In a world where the Internet scales,” says Callan, “OCSP is clearly the forward-moving infrastructure, and it’s used by all the newest browsers. Those browsers are all shipping with OCSP capability defaulted to on. There are some browsers, like the latest version of Opera, where you actually cannot turn it off. Our prediction is that, in the long run, there will be OCSP mandatory in every popular desktop browser. It really is a more robust, scalable, efficient infrastructure than CRL.”
That said, it remains important for businesses to support both approaches because older browsers don’t support OCSP.
The method of checking revocation status is important for data centers, particularly those running ecommerce operations. Low list latency and the speed of transactions are critical for security and smooth operations. But not all CAs are equal in this regard. According to Comodo, some have more efficient infrastructures in place than others.
“We sign our OCSP responses with the same CA key that we use to issue the SSL certificates themselves,” says Alden. “Although that sounds neither here nor there, it gives us a smaller response size, a smaller transaction for the OCSP—about a quarter of the size—and that helps cut down the cost of providing the service and also the time of latency.”
Alden also notes that some CAs base their OCSP service on a CRL list, leaving the OCSP at the mercy of the CLR’s latency. Moreover, many CAs only respond with a certificate status in the form of “it’s revoked” or “I don’t know.” If a cert was recently issued or was issued long ago but was never revoked, both of these could generate “I don’t know” responses.
Keep in mind that CRL and OCSP are not the last words in certificate authentication. The latest must-have in high-security browsing is EV (Extended Validation) SSL. When a browser lands on a site with an EV SSL certificate, the Address bar will turn green. Alongside the URL will be a small area showing your business’ name, the country in which the site is operating, and the CA’s name.
“Data center managers often ask me [about] extended validation—in particular, what happens when someone comes to a site with an EV cert and an old, pre-EV browser,” says Callan. “The answer is that they get the exact same experience they’d have with a non-EV cert. They still see 'https,' they still get the lock, the encryption. Obviously, they don’t get the green bar and the name of the organization, but there is no drop-off with the pre-EV browsers.”
Callan adds that over 70% of browsers are now EV-compatible, but managers should check their own records to see if EV is appropriate for their companies. EV is about creating increased assurance for the site visitor so that business can continue unimpeded. The more enterprises can tailor their certificate infrastructures around this concept, the more reward they’ll see from the investment.
by William Van Winkle