Certifiable Security Set the wheels of commerce in motion on your Web site.
by Peter H. Salus
The Web can be a great place in which to conduct commerce. The cost of entry for a company requires following a few simple steps, and possibly spearheading a solid public relations campaign to dispel fears customers might have about the unknown.
In a nutshell, these steps involve selecting a Web server capable of supporting secure transactions; acquiring a certificate from a Certifying Authority; configuring and testing your server; and possibly making changes in the corporate LAN environment to support these new services.
Getting That Secure Feeling
If you've read about setting up a secure Web server, you've probably encountered the acronym SSL (Secure Sockets Layer). SSL is a protocol that sits above the Communication Layers that transfer data between a browser and your HTTP server. Most people are content to know that when they reach a secure Web site, there's a cute key icon on the border of their browser window. However, if you're thirsty for all the juicy details, and math was your favorite subject, you can download the SSL 3.0 draft specification from http://home.netscape.com/newsref/std/SSL.html.
A number of vendors--including Netscape, IBM, O'Reilly & Associates, Process Software, and Microsoft--provide commercial-grade HTTP servers capable of supporting SSL. If you already have one of these products, then you are already halfway to supporting secure transactions at your site.
If you haven't yet selected an SSL-capable server and plan to host your Web site on Windows NT, you might want consider Microsoft's Internet Information Server (IIS). Not only is IIS free, but besides supporting SSL, it's one of the best performing Web servers available. You can download IIS directly from http://www.microsoft.com/iis/default.asp. Once Windows NT 4.0 is released, IIS is expected to be bundled with both the server and workstation versions of the operating system.
Acquiring the Certificate
The first step to configuring a secure Web site (besides making sure you've got the right server and that it is operating properly) is to acquire a digital ID, or certificate. A certificate is a specially coded object that uniquely identifies your site--much like a driver's license or passport identifies you. It contains your public key (for encryption), an expiration date, the name of your organization, and a digital signature of the issuer. A certificate is required no matter which vendor's HTTP product you've selected for secure Web serving.
Don't be misled into thinking that a certificate is automatically provided or that it comes with your Web server; you have to request one for each domain and server within your organization that you intend to host SSL on. Certificates are created and provided by Certifying Authorities. VeriSign is one such organization, and it provides certification services for all of the major Web servers.
Part of the process of acquiring a digital certificate is to uniquely identify your Web site using something called a "distinguished name"--a combination of several components, including Country, State/Province, Locality, Organization, Organizational Unit, and Common Name. An example of a distinguished name for a fictitious company located in Bellevue, Wash., might be:
"C=US, S=WASHINGTON, L=BELLEVUE, O=MYFIRM,
Once you've identified these components for your site, you can create a certificate request file. Each server vendor will supply a utility for generating this file. For Microsoft's IIS, you can use a program named keygen to prepare the data. For example,
"C=US, S=WASHINGTON, L=BELLEVUE,
O=MYFIRM, OU=SALES, CN=www.myfirm.com"
will generate a file named request.req containing your request encrypted with your public key (in this example, MyPassword1). The next step is to e-mail the data stored in request.req to the Certifying Authority. To ensure proper processing of your request, VeriSign asks that you include a copy of the command you typed to generate the file (be sure to exclude your password).
For Microsoft IIS users, requests can be e-mailed to microsoftre email@example.com. The process for Netscape's Commerce Server is slightly different in that a valid, identifying e-mail address is required, and your entry must be sent to firstname.lastname@example.org.
When submitting your request file to VeriSign, include payment information (you didn't think they were doing all this for free, did you?). Their charge for a one-year Digital ID for the first server in your organization is $290; additional server certificates cost $95 each. After one year, they all need to be renewed for $75 each.
If you have several organizational groups within your company that require secure Web services, but you don't want to set each one up with SSL, you might consider devoting a single system to handling secure Web traffic. Except for designating
https:// in your URLs, using SSL is all but transparent to the way you set up your directories. Even if you have several physically different Web servers, you can still refer to CGI programs and documents located on your secure site; just use a fully qualified URL. If you're collecting credit-card information, you must create forms and corresponding CGI or ISAPI programs on your secure site that know where to send their information. As long as you trust the integrity and security of the data within your organization, this approach will work fine.
Once your certificate has been sent to you, save the contents of the message to a text file. If you are working in Windows, copy the body of the message into a program such as Notepad, and then save the data to a file. Similar to how the request file was generated, each server product will have a different set of tools for installing the certificate. For IIS, simply use the
setkey program and provide the same password you used with
keygen, along with the name of your certificate file and the keypair.key file created when you built your original request. For example:
will enable SSL using the certificate data stored in cert.txt, for all virtual servers running on the system where that command was executed. If you're enabling a single virtual server, you can specify its IP address as an extra argument to the
If your company has a firewall installed and you've been able to browse the Internet, your firewall is set up to allow data transmission through port 80, the default port for the Web's HTTP protocol. SSL, by convention, uses port 443. Your browser knows this and switches to using that port whenever a site referenced by
https (the SSL-specific URL prefix) is used instead
If the Web server you're enabling SSL on is outside your firewall, clients that are external to your company will have no problem reaching your site. However, people within your company won't be able to reach it unless you "punch a hole" in your firewall. Placing a secure server inside your firewall, as opposed to outside, is recommended anyway, because you're collecting and storing confidential information. A server located on the inside has only a few well-known points of entry (such as FTP ports, HTTP port 80, and SSL port 443).
Browser and Content Considerations
If you're targeting the general public as potential clients for your secure Web site, it's safe to assume they'll be able to use a browser capable of supporting SSL. Even users on America Online, CompuServe, and Prodigy, who previously were offered only basic Web browsers, can now use browsers from Netscape and Microsoft.
As you prepare content for the secure portion of your site, try to minimize the number of pages that actually have to exercise the SSL features. Since all the data sent between your browser and Web server in secure mode is encrypted, it's possible for your system to incur an additional drain and decrease overall performance even while serving regular pages. Luckily, most sites will look to SSL only to provide an easy way of collecting payment information, and that usually entails only one or two forms where users can enter their credit card number and expiration date.
Will It Get Easier?
Supporting the transmission and receipt of confidential information through your Web site will always require some form of advanced encryption. Although the techniques and procedures described in this article paint a picture of agonizing detail, you can expect the process to get simpler over time, as vendors work to make the process more automated and understandable. But don't expect the role of the Certifying Authority to change or for companies like Microsoft or Netscape to assume that role. It's valuable for everyone's sake to keep the CA an independent resource, and it also makes it easier for you if your organization has to maintain certificates for multiple servers supported by multiple companies.
David Geller is director of online engineering for Starwave Corp., located in Bellevue, Wash.