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.
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.