Secure Webulator/400 sessions


This allows private conversations over the public Internet. Using Secured Webulator/400 sessions, you are able to have a browser obtain information off of your site that is encrypted. Even someone that can tap the wire between the machines cannot understand the communications.

The same is true for data typed into the Webulator/400 screen. Sensitive information such as user ids and passwords are protected using strong encryption technologies.


Secured Webulator/400 sessions 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.


Secured Webulator/400 sessions provide the visitors to your site confidence that they have reached your site and not someone else's site trying to impersonate your site.

Secured Webulator/400 Session Basics

In this section, a handful of concepts specific to doing secured sessions 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.


Non Secured Webulator/400 sessions serve HTML forms 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, Webulator/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.

There are three ways to set up Webulator/400 sessions. Webulator/400 can be configured to serve non secured sessions. This means the HTTP communications between the server and browser would not be encrypted. Webulator/400 can also be configured for secured sessions which means that all screens will be transmitted securely to the browser using SSL. And lastly, Webulator/400 sessions can be configured as a SSL Signon session. SSL Signon sessions can be thought of as a hybrid solution. Only signon screens will be encrypted using SSL. All other screens will use the standard HTTP protocol and will not be encrypted. You may want to consider using this approach if are willing to spend the extra CPU require for encryption to protect your user ids and passwords but do not consider the extra CPU requirements necessary for all other AS/400 screens.

Configuring session security is done on a per-session basis using the Allowed Protocols session based configuration value.

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 Webulator 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 Webulator/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 Webulator/400 server requires a server certificate if you wish to configure secured sessions. 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. Webulator/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.