How do security certificates work?
Securing transactions on the web

We've all seen them: Web sites with banners featuring a company that creates a secure connection. Lots of Web sites have them, particularly banks, auction sites and anyone who does business or sells goods and services on the Internet. You have seen the URL change from http:// (standard) to https:// (secure) and you have seen the padlock light up at the bottom of your browser, but how does this technology actually work? Is this the only use for SSL technology, or are there more ways this technology works for you? Certificates can be used to protect your personally identifiable information on the Internet, protect your computer from unsafe software, verify the identity of a person or the security of a Web site, provide secure connection to database servers and data streams and even establish a secure connection to your email server.

Basics of security certificate operations
A security certificate, whether it is a personal certificate or a Web site certificate, uses technology that associates an identity with a public key. Only the owner of the certificate knows the corresponding private key. This use of public / private key technology permits the owner to make a digital signature or decrypt information encrypted with the corresponding public key. Clear as mud, right? Think of it this way: You have a password associated with your user name. Only when the two pieces of information are put together in your computer and presented as a login are you given permission to access your data, email, etc. Using SSL technology (security certificates) is like your username and password on steroids. It allows you to send your information encrypted or digitally-signed.

How do certificates get installed?
In most cases, certificates are either installed when your system is loaded or when you go to a web site that requires them. Many of the so-called “trusted” sites have the keys installed on your system at load time. You may have seen a prompt like the one below. You go to a web location that requires a certificate, and you get a prompt. Some of these keys are public, some are private, but the idea is that there will be enough certificate information loaded on your PC that when you choose to install a new certificate, your system will be able to communicate with one of the trusted root certificate authorities to verify that the site you are connecting to is legitimate, has a valid certificate and is therefore worthy of your trust.
SSL Overview from the Customer's Browser viewpoint
OK, so now that you know how they get installed, you ask, how do they work? Consider the scenario of a Web site accessed from a Web browser. The browser checks the certificate to make sure that the site you are connecting to is the real site and not someone intercepting it. How is this done? When the site requested its SSL Certificate, it was bound to the fully qualified domain name (FQDN) of the site (that information is encrypted into the certificate request and registered with the Certificate Authority from which it was purchased and the web servers link that certificate to the unique IP address that is associated with the FQDN. Next, the browser determines the encryption types that both the browser and web site server can both use to understand each other. The browser and target Server send each other unique codes to use when scrambling (or encrypting) the information that will be sent. Finally, the browser and Server start “talking” using the encryption scheme they have exchanged information about, the Web browser shows the encrypting icon and Web pages are processed secured. Sounds simple, right?

How do I view my installed certificates?
With Internet Explorer, it’s simple to view installed certificates. All you need to do is:
1) Open Internet Explorer and on the Tools menu, click Internet Options
2) Click the Content tab
3) Under Certificates, click the Certificates or Publishers button to view the list of current certificates that you trust.
When you do, you will see a screen that shows you things like this graphic. These certificates typically have an expiration date. It is not like you can set up a trust relationship that lasts forever when you are talking about computer data. That is why periodically, you may be asked to install another certificate when you go to a site where you have been connected in the past. It also gives you the opportunity to decide if you still wish to allow access to the location from your computer.

Do You Use Certificates?
Many companies these days use security certificates for their servers, particularly if they have mobile users who travel with laptops. Users these days want the ability to use full fledged clients for sales, email, presentations and are no longer content with using thin- or Web browser-based clients, for the same reasons that today’s laptops rival the desktop systems of a few years ago in speed, memory and disk capacity. Using these certificates can have a downside. They expire, and when they are renewed, there is no overlap. As the relationship is based on “trust,” if something does not go smoothly during the transition, you will be unable to install a new certificate when the old one lapses. Another consideration is that you cannot install a certificate upgrade until the old one expires, as the resource cannot be accessed until the effective date is reached. Luckily, most certificates have terms of one to two years or longer.

How Do I Get One?
Certificates must be purchased. Which certificate you choose depends on the web server interface you are using. There are instructions for certificate installs for Apache, Apache on Cobalt, BEA Web Logic, C2Net Stronghold, CPanel, Ensim Control Panel, F5 Big IP, FirePass, Hsphere Web Server, IBM’s HTTP Server and WebSphere, Java Based Web Servers, Lotus Dominos Servers, Microsoft IIS – Outlook Web Access – ISA 2000 Server, iPlanet 4.1, Novell ConsoleOne, I-Chan, Plesk Servers, SSL Offloader, Website Pro, Webstart and Zeus Webserver. I apologize if I’ve omitted your favorite. There is a shorter list of companies that issue security certificates. Although there are a large number of entities who sell secure certificates, there are six primary SSL certificate providers. The SSL certificate you purchase will most likely be either one of these six or a reseller for one of them. All six have 128-bit key encryption. The primary SSL certificate providers are Verisign, Thawte, InstantSSL, Entrust, Baltimore and Geotrust . Just remember that it takes time to get one, sometimes more than 24 hours, particularly if you are applying for your first certificate. You may be asked to provide DUNS, Federal Tax ID’s, a credit card and billing information, so have this information ready and allow ample time before you apply. Planning with SSL is the key to success.

How can I get more information on this subject?
If you have support with us, ask us. Often, we will have additional suggestions about new solutions or emerging best practices. If you have questions or comments about this article, please contact me (JohnBoline@hagerman.com).

All product names / logos, company names / logos are copyrights of their respective holders. John Boline is an MCSE, CNE, USE and a member of the Network Professional Association. The content herein is often based on late-breaking events. Much of the material is based on information from sources that are believed to be reliable. Hagerman & Company, Inc. disclaims all warranties as to the ultimate accuracy or completeness of the information. Hagerman & Company, Inc. and its employees shall have no liability for errors, omissions or inadequacies in the information contained within this article or for any interpretations thereof. The recommendations, positions and best practice policies outlined herein represent Hagerman & Company, Inc. initial analysis and therefore are subject to change as further information which may have bearing on these positions is made available. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. Entire contents © 2006 Hagerman & Company, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden

 

This page last edited on Tuesday, September 19, 2006