CRTWWWKEY


CRTWWWKEY - Create Commerce Keys

The CRTWWWKEY command is used to create two files that are needed by Commerce Server/400 to support SSL encryption.
Keylist File
CRTWWWKEY generates and stores the server's private and public keys in an encrypted file called the keylist file. The keylist file is also used to store the server certificate. Commerce Server/400 requires this file when processing secure (i.e., SSL) ports. SSL cannot be processed until the signed server certificate, returned by the certification authority, is added to the keylist file with the ADDWWWCERT.

IMPORTANT: Make a backup copy of the keylist file after it is successfully created. The backup will be needed if there is a problem adding the correct signed server certificate to the keylist file.

Certificate Request File
The certificate request file contains formatted data that is required by a certification authority. The contents of the certificate request file is sent to the certification authority for signing.

CRTWWWKEY Parameters

NAME - Distinguished Name
This is the distinguished name of the site and AS/400 running Commerce Server/400. The name is used in Internet commerce to distinguish one server from another across all organizations. The distinguished name is bound by the certification authority with the generated public and private keys. The certification authority may reject the certificate request if the information is insufficient or incorrect.

The distinguished name is composed of six parts:

  1. Common Name
    The common name is a required parameter that must be set to the fully qualified domain/host name of the server. Some browsers will only process commerce transactions if the server's common name is the same as the host name in the URL. For example, www.inetmi.com

  2. Organization
    Name of the organization, company or individual that is hosting the Commerce Server. The organization name should be a non-abbreviated, legal name that is properly registered with a governmental unit. This parameter is required. For example, I/NET

  3. Country Code
    Required country in which the company or organization is located. This value must be the 2-character code for the country (e.g., United States is 'US', Canada is 'CA'). If you do not know your country code, contact your certification authority.

  4. Organizational Unit
    Optional organizational unit or company division/department. Also for Doing Business As... names. The unit should not be abbreviated. For example, Internet Division

  5. Locality
    Optional locality (e.g., city) of the company or organization. Required for organizations registered only at the local level. If the locality is specified the state or province must also be specified. For example, Kalamazoo

  6. State or Province
    State or Province in which the company or organization is located. In most cases the state or province should be provided. This parameter must be specified if locality is specified. Contact your certification authority for help in determining if the state or province is required. The state or province must not be an abbreviated value (i.e., do not use 'MI', use 'Michigan').

PASSWORD - Password
Password that is required to encrypt the server's keylist file. The password must be at least 8 characters in length and should follow good password guidelines (e.g., no repeating characters, use both letters and numbers). The same value must be passed into the STRWWW command when starting a Commerce Server that is using the created keylist file. If a case-sensitive password is desired the password must be enclosed in single quotes.

KEYFILE - Keylist File
Specifies the full-path to the keylist file that will be created. This file must not exist. The keylist file stores the public and private keys and the server certificate used by Commerce Server/400. Ensure that only authorized users have access to the keylist file. The server user profile must have access to read the keylist file.

The default keylist file is '/WWWServ/Key/KeyList.Cfg'. This file must be created in either the IFS root file system or the QDLS (shared folders) file system. It cannot be created in QSYS.

IMPORTANT: Make a backup copy of the keylist file after it is successfully created. The backup will be needed if there is a problem adding the correct signed server certificate to the keylist file.

CERTFILE - Certificate Request File
Specifies the full-path to the certificate request file that will be created. This file must not exist. The certificate request file contains formatted data, which includes the entered distinguished name, that is required by a certification authority. The certificate request must be sent (e.g., cut-and-paste into an e-mail message) to a certification authority to be signed.

The default certificate request file is '/WWWServ/WebDocs/CertRqs.Txt'. The file defaults to being created in the server's default document root directory. With the certificate request file in the document root, it can be viewed by a browser and then pasted into an e-mail message. You can move the certificate request file out of the document root once it has been sent to the certification authority. This file must be created in either the IFS root file system or the QDLS (shared folders) file system. It cannot be created in QSYS.

After the signed certificate is returned from the certification authority it must be added to the keylist file using the ADDWWWCERT command.

FORMAT - Certificate Request Format
The format of the certificate request to generate. Contact your certification authority for the preferred format. The following two formats are supported:

  1. *PEM
    Internet Privacy-Enhanced Mail (RFC1424) format.

  2. *PKCS10
    Public-Key Cryptography Standards format. This is the default format.

RSABITS - RSA Encryption Bits
The number of bits in the modulus value to be used by the RSA encryption algorithm. Increasing the number of bits increases the security of the data and the time required by the server to process encrypted data. Under most circumstances use the default value of 1024 (512 for the exported version). The exported version supports a maximum of 512.

WEEKS - Number of Weeks Valid
The number of weeks the generated public and private keys are valid. Due to rapid advances in computer technology the keys should be regenerated every few years. Under most circumstances use the default value.

This must be a value between 1 and 260. The default value is 1 year.


Authorizing a User to CRTWWWKEY

A user that does not have *ALLOBJ special authority must be authorized as follows to run the CRTWWWKEY command: