What is a Commerce Server?


NOTE:
The discussion contained here is only applicable to owners of Commerce Server/400. Web Server/400 owners cannot perform secured transactions.

Overview

What does Commerce Server/400 provide you that Web Server/400 doesn't?

Encryption

This allows private conversations over the public Internet. Using Commerce Server/400, you are able to have a browser obtain information off of your Web site in the same way that browsers access your Web Server/400 Web site today. But, when that data is transferred between machines, it is completely encrypted. Even someone that can tap the wire between the machines cannot understand the communications.

The same is true for data typed into an HTML form such as credit card numbers, secret codes, personal information, or sensitive corporate information. This data is protected using strong encryption technologies.

If you are using Webulator/400 today, you can install and configure Commerce Server/400 on your AS/400 and instantly have one of the most secure ways of accessing your AS/400 applications. Worried about signing on to your AS/400 over the Internet from home? With Commerce Server/400 encrypting your Webulator/400 session, you don't need to worry about someone grabbing your user ID and password or examining the screens you view.

Integrity

Commerce Server/400 essentially guarantees that the data sent between the browser and server is unaltered during transmission. This would detect both transmission errors due to noisy communication lines and malicious modifications possibly made by someone in the middle of the server and browser.

Authentication

Commerce Server/400 provides the visitors to your site confidence that they have reached your site and not someone else's site trying to impersonate your site. If someone were to make a purchase from you through your Web site, that person can be confident that they are giving a known company their credit card number and not an imposter.

Nonrepudiation

Commerce Server/400 provides proof that a document that is served off of your Web site was sent by you to the browser. For instance, this would allow you to provide a receipt for an online purchase, including the date of sale, promised delivery date, and price. The shopper can have confidence in this receipt because he or she can prove that your Web site knew of its contents before sending it.

Commerce Serving Basics

In this section, a handful of concepts specific to doing secured transactions over the World Wide Web are discussed. These concepts should be clear to anyone administering a secure Web site. The following section gets into more detail about how security is implemented. Understanding these topics is not critical, however the entire picture would be much more clear if these topics are also mastered.

HTTP and SSL

Commerce Server/400 can do everything Web Server/400 can do plus it can perform secured Web-based transactions. This means that if you own Commerce Server/400, there is no reason to also own Web Server/400 for the same machine. In fact, the two products install into the same location on the AS/400 so whichever product is installed last will be the one that is on your AS/400.

Commerce Server/400 and Web Server/400 both serve documents using the Hypertext Transport Protocol (HTTP). This protocol does not perform encrypted transactions. The data sent between the browser and server is sent "in the clear," meaning that anyone that can tap into the wire connecting the two machines can eavesdrop on the conversation.

In addition to HTTP, Commerce Server/400 can also be configured to encrypt the conversation by interfacing with the Secure Sockets Layer (SSL) protocol. If both the server and browser are communicating through SSL, then the HTTP conversation is done securely. The Secure Sockets Layer encrypts data as it leaves one machine and decrypts it as it arrives at the other.

Three ways to set up Commerce Server/400 exist. Commerce Server/400 can be configured to behave just like Web Server/400. This means the HTTP communications between the server and browser would not be encrypted. Commerce Server/400 can also be configured to only communicate securely with browsers using SSL. And lastly, Commerce Server/400 can be configured to serve some documents securely using SSL and some without encryption using only HTTP. This is done on a per-directory basis using the Allowed Protocols directory based configuration value.

The first two methods can be combined to form a fourth option. You can start one instance of Commerce Server/400 to handle only regular HTTP requests and another to handle only SSL requests. This can be done by making a separate copies of the WEBSERV.CFG and ACCESS.CFG configuration files for the SSL server (e.g., SECURE.CFG and SACCESS.CFG). The HTTP-only server would set the Protocols configuration value to HTTP. The SSL-only server would set the Protocols value to SSL and probably change the Document Root, Include Libraries, Script Libraries, and possibly other configuration values. Also, the SSL-only server would need an Allowed Protocols of SSL in the root directory of the directory based configuration file (e.g., SACCESS.CFG).

Server Certificate

Every server implementing secured transactions requires a server certificate. This is used to identify the Web site and to provide browsers with the Web site's Public Key. The public key is used to provide encryption, integrity, authentication and nonrepudiation. Server certificates are obtained from a Certification Authority such as VeriSign, Inc. A series of commands are provided to assist in the creation of a server certificate for a Web site.

Keylist Database File

A Web site's security information is stored in the keylist database file. This file is encrypted using a user-supplied password. The file is reasonably protected by being encrypted, but it should also be physically guarded as much as possible.

The server's certificate, public key, and private key are all stored in this file. The public and private keys are very large numbers that are used to perform the secure transactions. Only the private key needs to be closely guarded. The server's certificate and public key can be freely distributed.

The server certificate, public key and private key are all interrelated and must be kept together in the same keylist database file. If a Web site has more than one certificate, then multiple keylist database files will be needed. This might be the case if a Web site is using Multi-home support to host multiple secure Web sites on the same machine. Each instance of the server could either share the same keylist database file (and certificate) or use its own.

How Does Commerce Server/400 Do This?

The exact details of how secure electronic communications are done are not important, but a few of the pieces can be helpful. The above listed features of a trusted Web site are accomplished using 1) Server Certificates, 2) Private and Public Keys, 3) Public Key Cryptography, and 4) Bulk Encryption Algorithms.

Server Certificates

Every Commerce Server/400 server requires a server certificate. This is used to both prove its identity and to exchange encrypted information with browsers. The certificate contains a distinguished name of the server which is used to uniquely identify the server to visitors, it contains the server's public key, and it contains a digital signature of a Certification Authority.

Distinguished Name
This consists of information that uniquely identifies your Web site. Values such as the Internet host name of the machine, the company's name, and the State and country of the company. The Certification Authority will validate this information before providing a company their server certificate.

Public Key
The public half of a Web site's encryption key. Visiting browsers use this value to communicate securely with the server. This is described more below.

Certification Authority
A Certification Authority (CA) provides server certificates. Before a company can begin doing secure transactions, they need to request a server certificate from a CA. The CA will verify the identity and validity of the company's request for a server certificate and then provide a digitally signed server certificate. The company will then install this certificate into their Web server software.

Digital Signature
Using sophisticated mathematical algorithms, a digital signature of a document can be created that proves the identity of the signer and verifies the contents of the document. In the case of a server certificate, if the CA digitally signs the distinguished name and public key portions of the certificate, then anyone that trusts the CA can be confident that the certificate has not been changed.

Private and Public Keys

Part of the process of generating a server certificate is generating a pair of large numbers. One of these numbers, the public key, is shared with everyone who wants to communicate with the Web site. The other number, the private key, is only known to the Web site and its administrator(s). The private key is held in the strictest of confidence. Commerce Server/400 stores this in its keylist database file, encrypted using a user-supplied password.

Public Key Cryptography

Public Key Cryptography is used to do two things: exchange bulk encryption keys and verify digital signatures. What is special about Public Key Cryptography is that anyone who knows a person's public key can use it to encrypt a message for that person that no one else can understand. The only way to decrypt that message is using the private key half of the public and private key. The opposite is also true: Something encrypted with a private key can only be decrypted with the public key. This allows two parties to communicate without previously exchanging a secret password.

In terms of Web serving, the Web site's public key is provided to anyone that wants to securely communicate with that server. This is done by sending the server's certificate (which contains the public key) to a browser that wants information from the server. The browser then uses the server's public key to encrypt a password that will be used to encrypt the rest of the communication between the server and browser. Since the server is the only one that knows its private key that can decrypt something encrypted with its public key, the server is the only one that can successfully decrypt the password.

Public Key Cryptography is also used to verify digital signatures. When a CA digitally signs a certificate, it is really encrypting a piece of the certificate data using the CA's private key. When a browser wishes to verify that signature, it decrypts the signature using the CA's public key and compares it to the certificate data. If they match then the digital signature is valid.

Bulk Encryption Algorithms

In the discussion on Public Key Cryptography, the browser encrypted a password that would then be used by both sides to encrypt the rest of the data. Public Key Cryptography could be used to do all the encryption between the browser and server, but it has two disadvantages: This would require that the browser also has a public and private key so the server can securely encrypt data sent to the browser. And, Public Key Cryptography is computationally very expensive.

Instead of using Public Key Cryptography for the entire transaction, only a secret key, or password, is exchanged using this algorithm. Then this secret key is used by both sides to perform simpler and faster bulk encryption algorithms.