Setting Up Secure Messaging Environments

This chapter discusses how to:

Work with digital certificates.
Implement authentication and nonrepudiation.

Understanding Secure Messaging

This provides an overview of types of messaging security, digital certificates and nonrepudiation.

Types of Messaging Security

Secure messaging with PeopleSoft Integration Broker can include three types of security:

Authentication.	This is the ability to securely identify the sender of a message. It can be accomplished using a password or a digital signature.
Nonrepudiation.	This is an enhanced form of digital signature authentication with two benefits. It ensures that neither participant in a transaction can disavow participation, and it guarantees the integrity of the message content.
Encryption.	This type of security supports privacy. The sender translates the content of a message into a secret code that only the receiver can decrypt. PeopleSoft Integration Broker employs the SSL protocol for encryption.

Digital Certificates

All of these security types (except password authentication) use digital certificates. A digital certificate is a form of electronic ID card that supports public key encryption technology. Each messaging participant generates a matched pair of encryption keys—a private key, which is never revealed or transmitted, and a public key, which is freely available to other participants. These keys are stored in a local file or repository called a keystore, and the public key is stored as part of a digital certificate. The certificate can be attached to a message to verify the sender's identity and to provide the recipient with the means to encode a response.

Digital signature authentication and nonrepudiation both use digital certificates to provide the keys to generate the necessary signatures. You use PeopleSoft Security to install digital certificates in each node's application server keystore to support these features.

SSL implements encryption using a public key infrastructure (PKI), for which the digital certificates provide the keys. When you use an HTTP listening or target connector to exchange messages with a third-party system or a remote gateway across a firewall, SSL encryption is not implemented by default. To implement SSL for these cases, you must install digital certificates on the participating gateways.

Note. SSL on an integration gateway incorporates an authentication element, which is different from message authentication at a PeopleSoft Integration Broker node. SSL authentication does not need to be configured separately. Consequently, in this PeopleBook, the term SSL encryption refers to the combined elements of SSL, including SSL authentication.

Implementing SSL encryption for messaging requires installing two sets of digital certificates to support the two complementary parts of SSL:

SSL with server authentication, which secures inbound messages.

You use software supplied with your BEA WebLogic or IBM WebSphere web server to install digital certificates in the web server's keystore.
SSL with client authentication, which secures outbound messages.

You use a Java command line utility provided with the gateway's PeopleSoft Pure Internet Architecture installation to install digital certificates in the gateway's keystore.

See Also

Working With Digital Certificates

Nonrepudiation

PeopleSoft Integration Broker applies nonrepudiation to cross-node messaging by digitally signing request messages and their responses.

In PeopleSoft applications, nonrepudiation provides two-way protection; both the request message and its response are nonrepudiated. PeopleSoft Integration Broker uses PKI technology to implement nonrepudiation for messaging. Each participating node’s keystore contains its own private key and the public keys of the nodes with which it exchanges nonrepudiation messages.

Here’s how nonrepudiation works:

Node A generates a number, known as a digest, which uniquely identifies its request message.
Node A uses its private key to generate a signature based on the digest, and inserts the signature into the nonrepudiation request message.
Node A sends the nonrepudiation request message to node B.
When the nonrepudiation request message is received, node B uses node A’s public key in its keystore to confirm the integrity of the digest.

It then separately recreates the digest from the message, and compares it to the received digest to confirm the message integrity.
Node B generates a digest that uniquely identifies its response message.
Node B uses its private key to generate a signature based on the digest, and it inserts the signature into the nonrepudiation response message to confirm receipt of the nonrepudiation request message.
Node B sends the nonrepudiation response message to node A.
When the nonrepudiation response message is received, node A uses node B’s public key in its keystore to confirm the integrity of the digest.

It then separately re-creates the digest from the message and compares it to the received digest to confirm the message integrity.

Nonrepudiation produces the following results:

The sending node cannot repudiate that the message was sent, because the receiving node has a copy of the request signed by the sender.
The receiving node cannot repudiate that the message was received and processed, because the sending node has a copy of the response signed by the receiver.
The message integrity is verified, because the validated signature of each nonrepudiation message assures that the message content as received exactly matches the content as sent.

Working With Digital Certificates

This section provides overviews of certificate authorities and certificate installation elements and discusses how to:

Access certificate properties.
Export and convert certificates.

Understanding Certificate Authorities

A certificate authority (CA) is a trusted third-party organization or company that issues digital certificates used to create digital signatures and encryption keys. The role of the CA in this process is to guarantee the identity of the party granted the certificate. Usually, this means that the CA has an arrangement with a financial institution that provides information to validate the grantee's identity.

To install digital certificates for secure messaging, you must select a CA from whom to obtain the certificates. There are many CAs to choose from, and most of them do business on the World Wide Web. Some of the best known are:

Verisign, Inc.
Entrust Technologies.
Baltimore Technologies.
Thawte.

There are also numerous lesser known CAs, which might be appropriate if they are well known in a particular geographical region or industry. One of the systems participating in a secure integration might even serve as CA for the other participants. Each CA provides a unique set of security services and has its own way of handling digital certificates.

Before you implement secure messaging with PeopleSoft Integration Broker, investigate the available CAs, select one or more from whom you will obtain digital certificates, and familiarize yourself with their policies and procedures.

Understanding Certificate Installation Elements

Whether you implement digital signature authentication, nonrepudiation, or SSL encryption, you need to use digital certificates. Although these security features require you to use a variety of programs and procedures, some characteristics of digital certificates—including the process of obtaining, installing, and configuring them—are common to all three features.

Depending on the security feature, you might install digital certificates in the keystore of an application server, a web server, or an integration gateway. An implementation of digital certificates on each of these entities involves the following elements:

The entity's private and public encryption keys.
A distinguished name (DN) for the entity.
A certificate signing request (CSR).
A certificate containing the entity's public encryption key, signed by a trusted CA.
A root certificate from the trusted CA.

The following sections discuss these elements in more detail.

Public and Private Encryption Keys

For a given keystore, you generate private and public encryption keys simultaneously as a matching pair with software provided by the entity.

DN for the Entity

A DN is a property commonly used in security environments to uniquely identify a person, system, or network node. The DN is usually stored as a string of name-value attribute pairs separated by commas and spaces. You must provide the DN attribute values to generate a private key. These attributes include:

Common name (CN)	The name of the entity, expressed as a machine name, domain name, node name, or a name that you create, depending on the environment; for example, QE_LOCAL.
Organization unit (OU)	The part of the organization to which the entity belongs; for example, Accounts Receivable.
Organization (O)	The name of the organization or company; for example, PeopleSoft.
Locality (L)	The city or equivalent locality of the organization; for example, Pleasanton.
State (ST)	The state, province, or equivalent region of the locality; for example, California.
Country (C)	The country of the locality; for example, US.

CSR

This is a document that contains the entity's public key. The CSR is typically generated in Privacy Enhanced Mail (PEM) format, which is base 64–encoded binary data. PEM is a standard text-based format for storing and transmitting digital certificates. You use the same software to generate the CSR that you use to generate the private-public key pair. The following example shows a CSR:

-----BEGIN NEW CERTIFICATE REQUEST----- MIIBkTCB+wIBADBSMQswCQYDVQQGEwJ1czELMAkGA1UECBMCY2ExDTALBgNVBAcTBGhlcmUxCzAJ BgNVBAoTAndlMQ0wCwYDVQQLEwR1bml0MQswCQYDVQQDEwJtZTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEApaGAHNBjuByh8qXFCz33TgLzUjRm8S6tijit7fw23rKWyipQ0VgqeAD6eHr0pini lyJPPOiJJ5fY0h2h78hOr8o+nJosTcqZL3jP+rSVick7qPPyXjcxP1UCGz/8RNykFDnbwjziwi+p MesoWa8hfBss0ga2zZsmlV8Q4SyYE3UCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBACt0owTCngrU /HAMAZgT/2O6hiZaD4OVBrgLYzmRvUiVhKOyTUzUv57ks7U6DQYt+rnWwNJtVbeAqO5eZiT7hXbj Pwl8lGj+Adb6FGYOt4OhicZ0gNMHtURVop6iNJ9scxOmVcpkO0yX5f1rWFdZ0KZrWZSFGI6Lwdud Hvbyvbpz -----END NEW CERTIFICATE REQUEST-----

Signed Public Encryption Key From CA

The process of obtaining a signed public key certificate from a CA depends on the CA that you select. Typically, it requires you to paste the content of the PEM-formatted CSR into a form that you submit online. The CA then creates, digitally signs and returns a public key certificate to you. The CA will either email you the certificate or require you to download it from a specified web page. The certificate can be either PEM or the binary Distinguished Encoding Rules (DER) format. Following is an example of a PEM-formatted certificate:

Root Certificate

The root certificate contains the CA's digitally signed public key. It's also known as a chain file or a signer certificate. The process of obtaining a root certificate from a CA depends on the CA. The CA typically sends an email with the certificate or requires you to download it from a specified page.

The signed public key certificate also contains an embedded copy of the CA's root certificate, which you can export.

Accessing Certificate Properties

When you need to install a signed public key certificate in a keystore, you need the issuing CA's root certificate in the keystore as well. Your public key certificate is more than a single certificate; the same file contains the issuing CA's root certificate as well. If you do not receive a separate root certificate from the CA, you can access it from the public key certificate properties.

When you need to export a root certificate or examine the certificate's valid dates—or when you need to convert a certificate between DER and PEM formats—use the security extensions on a Windows NT or Windows 2000 machine to access the certificate properties dialog box .

To access certificate properties:

Double-click any certificate file with a .DER (binary format) extension or a .CER (PEM format) extension.

This invokes the Windows extensions for security management, which open a dialog box so you can inspect the certificate properties.
(Optional.) Access the properties of the embedded root certificate.
1. Select Certification Path.
  
  A tree structure appears, showing the hierarchical chain of trust between the public key certificate and its issuer root certificate. Your certificate has the common name that you supplied for it, and the issuer root certificate (its parent) has the name of its issuing CA.
2. Select the root certificate, and click View Certificate.
  
  A dialog box display the properties of the root certificate.
(Optional.) Select Details.

A list of fields appears. Click a field name to examine its value. This is especially useful for determining the certificate's Valid From and Valid To date and time.

Exporting and Converting Certificates

You might need to export an embedded root certificate or convert an existing certificate from DER format to PEM format. You can export certificates from:

DER or PEM formatted certificate files.
Certificate rows in a PeopleSoft application server keystore.

To export or convert a certificate from a file:

Access the properties dialog box of the certificate to export or convert.

See Accessing Certificate Properties.
In the certificate properties, select Details, then click Copy to File.

The Certificate Export Wizard launches.
Click Next, then select a format.

Base64-encoded X.509 (.CER) is the PEM format option, which is recommended. The DER encoded binary X.509 (.CER) option may also work, depending on the environment.
Click Next, and then browse to select a location and file name for the new certificate file.

Specify the same location as the certificate. Ideally, you should give an exported root certificate file the same name as the issuing CA.
Click Next, then Finish to save the root certificate file.

A message indicates when the export is successful.

To export a certificate from an application server keystore:

In the PeopleSoft Pure Internet Architecture, sign on to the application database and select PeopleTools, Security, Security Objects, Digital Certificates.

The Digital Certificates page appears.
Click the Detail link of the desired certificate, then click Export.

The Export Certificate page appears, containing the exportable certificate content in a long edit box.
Copy the entire certificate content and sign out of the database.

Note. Save this certificate content to a file with a .CER extension.

The following example shows the Certificate Detail page:

Implementing Authentication and Nonrepudiation

This section discusses how to:

Install node-based digital certificates.
Configure authentication.
Configure nonrepudiation.

Note. PeopleSoft Integration Broker uses node-based digital certificates to generate digital signatures for authentication and nonrepudiation, but not encryption. External SSL encryption is provided by the digital certificates that you install separately on the gateway's web server.

Installing Node-Based Digital Certificates

At each node that participates in authenticated or nonrepudiated transactions, you must install digital certificates in the node's application server keystore. Any participating third-party system must have a set of certificates complementary to those installed at the PeopleSoft nodes. You use the PeopleSoft Security Digital Certificates page to install the certificates, as shown here:

Each node requires three types of certificates:

One root certificate from a trusted CA.

This certificate contains the CA's digitally signed public key. Each root certificate is stored in a record of type Root CA in the keystore.
One certificate containing the default local node's public key, signed by the same trusted CA.

The CA's root certificate must be installed before you install the default local node's certificate, which is stored in a record of type Local Node in the keystore.
One or more certificates containing the public keys of the remote nodes that participate in authenticated or nonrepudiated messaging.

Each of these certificates is stored in a record of type Remote.

Note. Each remote certificate is a copy of the local node certificate this is installed on the remote node that it represents.

Consequently, you must first establish a root CA certificate and install a local node certificate on node A before you can export a copy of that certificate to node B. The simplest approach is to first install a certificate of type Root CA and a certificate of type Local Node on each of the participating nodes. Then you can export each of the local node certificates and import them to the other nodes as type Remote.

Installing Root Certificates

You can use one of the existing root certificates delivered with the PeopleSoft application, or you can install a new one from a different CA. Either way, you must have a CA's root certificate installed before you can obtain the default local node's signed public key certificate from that CA.

To install a new root CA certificate:

Obtain a root certificate from the selected CA.

You can obtain the certificate in several ways:
- Go to the CA's web site and request a signed, PEM-formatted copy of the CA's root certificate.
  
  The process of obtaining a root certificate from a CA depends on the CA.
- Export the root certificate from a public key certificate previously issued by that CA, or export it from an existing root CA row in another PeopleSoft application server keystore.
  
  See Exporting and Converting Certificates.
In the PeopleSoft Pure Internet Architecture, select PeopleTools, Security, Security Objects, Digital Certificates.
On the Digital Certificates page, add a new row, and select the type Root CA.
In the Alias field, enter the name of the CA, then click the lookup button for the Issuer Alias field.

Both fields should have the same value, and the new certificate's row should contain an Add Root link.
Click Add Root.

The Add Root Certificate page appears.
Open the downloaded or exported root certificate file in a text editor and copy its certificate content, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
Paste the copied certificate content into the long edit box on the Add Root Certificate page and click OK.

The Digital Certificates page reappears. The new certificate's row now contains a Detail link, which you can use to examine the certificate.

Installing Signed Public Key Certificates

To install a signed public key certificate, you must define a local node certificate row in the keystore, then obtain the signed certificate from a CA whose root certificate is installed. To do this, you generate a CSR, submit the CSR to the CA, then retrieve and import the content of the signed certificate into your certificate row.

To install a signed public key certificate:

On the Digital Certificates page, add a new row, and select the type Local Node.
In the Alias field, enter the name of the PeopleSoft Integration Broker default local node.

You do not need to configure the default local node yet; however, you must use this name when you do configure it.

See Configuring Nodes.
Select the issuer alias of the root CA certificate whose CA you want to sign the local node certificate. The new row now contains a Request link.

Click the Request link to open the Request New Certificate page. You use the Request New Certificate page, shown here, to import the new local node certificate:

To obtain and import the new local node certificate:

On the Digital Certificates page, click the Request link for the new certificate.

The Request New Certificate page appears.
Enter the subject information in the fields provided.

These fields represent attributes of the default local node's DN. The CA to whom you submit the CSR might require values for any or all of them. The DN will also be stored on the Detail page of the local node certificate. For the common name, enter the name of the PeopleSoft Integration Broker default local node.

See Understanding Certificate Installation Elements.
Select the key encryption algorithm that this certificate uses, or accept the default value.
Select the key size that this certificate uses:
- A 1024-bit key provides 128-bit encryption.
- A 512-bit key provides 40-bit encryption.
(Optional.) Enter an email address.

This information is also stored on the Detail page of the certificate as a DN attribute called mail.
Click OK to generate a new CSR.

The Certificate Signing Request page appears, containing the CSR in a long edit box.

Note. In addition to generating the CSR, which contains the default local node's public key, this step also creates the matching private key, which is automatically installed in the same row of the node's keystore.
Copy the certificate request portion of the text.

Include the -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST----- lines.

Note. Save this CSR content to a text file.
Click OK.

The Digital Certificates page reappears. The new row now contains an Import link.
To obtain your local node certificate, submit the CSR to the CA that issued the selected root certificate.

The process of obtaining digital certificates varies, depending on the CA. Typically, a CA requires you to paste the content of the PEM-formatted CSR into a form that you submit online.

The CA may send you the signed public key certificate by email or require you to download it from a specified web page.
Open the saved certificate file in a text editor, then highlight and copy its entire contents, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
Return to the Digital Certificates page and click the Import link for the new certificate.

The Import Certificate page appears.
Paste the copied certificate content into the long edit box and click OK.

Three outcomes are possible.

The following message may appear: Could not decode PEM-formatted certificate data. This indicates either that the pasted content isn't formatted properly as a certificate, or that the certificate is not yet valid.

Every signed digital certificate has a period of time during which it can be used, specified by its internal timestamp fields, Valid From and Valid To, which are set by the signing CA. The timestamps were inserted by the CA's certificate server. You can't import the certificate content until the Valid From time has passed on your default local node's application server, which may lag by several minutes, depending on the relative clock accuracy of the two servers. (Note that time zones are automatically accounted for and have no effect on this issue.) You must examine theValid From field in the certificate's properties dialog box to determine when the certificate can be imported.

See Accessing Certificate Properties.

Alternatively, the following message may appear: The certificate signature is not valid. The certificate is corrupt or has been modified. This indicates either that the certificate has been tampered with, or that the keystore contains no root certificate signed by the same CA.

The issuer alias of a root certificate doesn't always reflect which CA actually signed the certificate. Therefore it's possible that the CA to which you submitted your CSR didn't sign any of your installed root certificates. The local node certificate in your keystore must be accompanied by a root CA certificate signed by the same CA. See the following section to resolve this root certificate mismatch.

The third possibility is that the Digital Certificates page reappears and the new certificate's row now contains a Detail link. In this case, the certificate has been successfully installed, and you can proceed to install remote certificates for the node.

Note. The new certificate's row may contain a different issuer alias than the one that you selected for it. This indicates that the keystore contains a root certificate signed by the same CA that signed the new certificate, but it wasn't the one with the issuer alias that you selected (the issuer alias of a root certificate doesn't always reflect which CA actually signed the certificate). PeopleSoft Integration Broker has changed the issuer alias for the new certificate to correctly reflect which root certificate is its parent.

Resolving Root Certificate Mismatches

To import a signed public key certificate to the application server keystore as a row of type Local Node on the Digital Certificates page, a root certificate signed by the same CA that signed the public key certificate must already exist as a Root CA row on that page.

If you cannot import a signed public key certificate because no matching root certificate exists, you can resolve the deficiency by installing the root certificate of the CA that did sign your public key certificate. Then you obtain a new signed public key certificate from that CA.

To resolve a root certificate mismatch:

Export the embedded root certificate from the signed public key certificate file.

See Exporting and Converting Certificates.
Define a new root CA certificate in the keystore.

Refer to the previous procedure for establishing a root certificate.
Delete the local node row from the keystore's Digital Certificates page.
Add a new local node certificate to the keystore using the same issuer alias as the new root CA certificate.

Refer to the previous steps for installing a signed public key certificate.

Installing Remote Certificates

To establish two-way authentication or nonrepudiation, each node must possess copies of the other participating nodes' public keys. You accomplish this with a certificate row of type Remote in the default local node's application server keystore, which contains a certificate exported from the row defined as Local Node in a remote node's keystore. You define one remote certificate for each participating remote node.

The following requirements apply:

The remote system's local node certificate must already be installed.

Refer to the previous steps for installing a signed public key certificate.
The local system must have a root certificate installed with the same issuer alias (and actual issuer) as the remote system's local node certificate.

Refer to the previous steps for establishing a root certificate.

Note. For the purposes of this discussion, assume that both local and remote nodes are PeopleSoft applications. If the remote node is a third-party system, the same requirements must still be satisfied—the third-party system must provide a copy of its signed public key certificate to the PeopleSoft node.

To install a remote certificate:

Export a copy of the remote system's installed local node certificate.

See Exporting and Converting Certificates.
In the PeopleSoft Pure Internet Architecture, sign on to the local database and select PeopleTools, Security, Security Objects, Digital Certificates.

The Digital Certificates page appears.
Add a new row, and select the type Remote.
In the Alias field, enter the name of the remote node.

You do not need to define the remote node yet; however, when you do define it, you must use the name that the remote system uses for its default local node.

See Configuring Nodes.
Select the issuer alias of the remote system's local node certificate.

The new certificate's row now contains an Import link.
Click Import.

The Import Certificate page appears.
Paste the content of the exported public key certificate into the long edit box and click OK.

The Digital Certificates page reappears. The new certificate's row now contains a Detail link.

See Also

Working With Digital Certificates

Configuring Authentication

You can implement authentication functionality with passwords or digital signatures.

Password Authentication

To implement password authentication, you select the Password option from the Authentication drop-down list in a node definition, and enter a password. When you do this for a default local node definition, you must enter the same password in any remote node definition that represents the same node on the other participating systems.

See Creating Node Definitions.

Digital Signature Authentication

Digital signature authentication involves the following tasks:

You must supply the digital certificates containing the private and public keys required for authenticated transactions.

These elements are required at every node that participates in an authenticated transaction; PeopleSoft Integration Broker handles the mechanics of applying the keys.

See Installing Node-Based Digital Certificates.
You must select the Certificate option from the Authentication drop-down list in a node definition.

When you do this in a default local node definition, you must select the same option in any remote node definition that represents the same node on the other participating systems.

See Creating Node Definitions.

Configuring Nonrepudiation

Nonrepudiation functionality requires the following tasks:

You must supply the digital certificates containing the private and public keys required for nonrepudiation transactions.

These elements are required at every node that participates in a nonrepudiation transaction; PeopleSoft Integration Broker handles the mechanics of applying the keys.
You must select the Non-Repudiation check box in the properties of a message definition to indicate that it’s a nonrepudiation message.

When you do this on one system, you must select this option on the same message definition on every system that will participate in transactions using this message.
You must select the Non-Repudiation check box in a node definition to indicate that it supports nonrepudiation.

When you do this in a default local node definition, you must select the same option in any remote node definition that represents the same node on the other participating systems.
To save nonrepudiation messages for future reference, you must make sure that they are archived.

With both archived and active nonrepudiation messages, you can regenerate the digest in PeopleSoft Integration Broker Monitor to reconfirm that it matches the attached digest.

If a participating node doesn’t use PeopleSoft Integration Broker, that node is still responsible for managing the appropriate private and public keys, inserting properly formatted signatures in the nonrepudiation messages it sends, and properly handling signatures in messages it receives.

Complying With Message Formatting and Transmission Requirements

Defining Message Channels and Messages

Configuring Nodes

Using Integration Broker Monitor

Setting Up SSL Encryption

This section discusses:

Set up digital certificates for server authentication SSL for BEA WebLogic.
Set up digital certificates for server authentication SSL for IBM WebSphere.
Set up digital certificates for server authentication on application servers.
Install digital certificates for client authentication SSL.
Configure SSL encryption.

Understanding Installing Digital Certificates for Server Authentication SSL

You use utilities provided with the BEA WebLogic or IBM WebSphere server software to install web server-based certificates for SSL with server authentication. This authentication secures inbound messages. The web server requires three elements:

The web server's private key.
A certificate containing the web server's public key, digitally signed by a trusted certificate authority (CA).
A root certificate from the CA that signed the web server's public key.

The information in section outlines the basic steps required to obtain and install the certificates and keys that you need. Because both WebLogic and WebSphere are third-party proprietary products—and each provides its own interface and methodology for establishing server authentication SSL—you should refer to the documentation supplied with the web server software for detailed information about this process. In addition, refer to the information supplied by the selected CA.

Note. PeopleSoft delivers a number of certificate authorities and root certificates. If your certificate authority or root certificate is not listed, you need to add it to the PeopleSoft system.

You use the web server software to generate its own private key. At the same time, it also generates a certificate signing request (CSR), which contains the web server's public key. You submit the CSR to the selected CA, which creates, digitally signs, and returns your web server's public key certificate to you. This certificate might be in standard DER-encoded binary format; however, it can be converted to PEM format if necessary. You then install both signed certificates, and you register them and your private key with your web server, so that the web server recognizes and uses them.

Installing Digital Certificates for Server Authentication SSL on BEA WebLogic

This section describes how to install digital certificates for server authentication SSL for the BEA WebLogic environment and discusses how to:

Generate and import public keys.
Generate private keys and CSRs.
Submit CSRs to CAs for signing.
Import signed private keys into keystores.
Set up gateway private keys.
Set up BEA WebLogic Console for SSL.

Generating and Importing Public Keys (WebLogic)

Before you can generate and import public keys into PeopleSoft, you must access and download the signed public key from your CA. The process for accessing and downloading the signed public key varies, depending on your CA. Contact your CA for information on how to perform these tasks.

To generate and import public keys:

Place the public key from your CA in the keystore. The location of the keystore is:
```
<PS_HOME>\webserv\peoplesoft\keystore
```
Open PSKeyManager.
1. Open a command prompt and navigate to <PS_HOME>\webserv\<domain>.
2. Enter the following at the prompt:
```
pskeymanager -import
```
3. At the Enter current keystore password prompt, enter the password and press Enter.
At the Specify an alias for this certificate prompt, enter the alias name and press Enter.

The alias name you enter must be the same one you entered when you generated the private key.
At the Enter the name of the certificate file to import prompt, enter the path and name of the certificate to import, and press Enter.
At the Trust this certificate prompt, enter Yes and press Enter.

Generating Private Keys and CSRs (WebLogic)

You use PSKeyManager to generate private keys. PSKeyManager is a wrapper to Sun Microsystem's Keytool for managing keys and certificates.

While using PSKeyManager, press the Enter key to select any of the default values presented.

To generate the private key and the CSR on BEA WebLogic:

Start PSKeyManager.
1. Open a command prompt and navigate to <PS_HOME>\webserv\<domain>.
2. Enter the following at the prompt:
```
pskeymanager -create
```
  PSKeyManager opens.
Enter the current keystore password and press Enter.

The default password is password.
At the Specify an Alias for this Certificate <host_name>? prompt, enter the certificate alias and press Enter.

The default certificate alias is the local machine name.
At the What is the common name for this certificate <host_name>? prompt, enter the host name for the certificate. For example:
```
<host_name>.corp.peoplesoft.com
```
Press Enter.
Enter the appropriate information at the following prompts. Press Enter after each entry.
1. Organization unit.
2. Organization.
3. City of locality.
4. State or province.
  
  You must spell out the entire state name. Do not enter an abbreviation.
5. Country code.
6. Number of days the certificate should be valid.
  
  The default value is 90.
7. Key size to use.
  
  The default value is 1024.
8. Key algorithm.
  
  The default value is RSA.
9. Signing algorithm.
  
  The default value is MD5withRSA.
At the Enter a private key password prompt, enter the password or press Enter to use the keystore password.
Verify that the values you entered are correct, and press Enter. To go back and change any values, enter No and press Enter.

PSKeyManager generates a private key and provides the certificate signing request (CSR) that you will provide to the CA for signing. The following example shows a sample CSR.

-----BEGIN NEW CERTIFICATE REQUEST----- MIIBtDCCAR0CAQAwdDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0FyaXpvbmExEDAOBgNVBAcTB1Bob2VuaXgxFDASBgNVBAoTC1Blb3BsZVRvb2xzMRMwEQYDVQQLEwpQ ZW9wbGVzb2Z0MRYwFAYDVQQDEw1NREFXU09OMDUxNTAzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC43 lCZWxrsyxven5QethAdsLIEEPhhhl7TjA0r8pxpO+ukD8LI7TlTntPOMU535qMGfk/jYtG0QbvpwHDYePyNMt Vou6wAs2yr1B+wJSp6Zm42m8PPihfMUXYLG9RiIqcmp2FzdIUi4M07J8ob8rf0W+Ni1bGW2dmXZ0jGvBmNHQI DAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAKx/ugTt0soNVmiH0YcI8FyW8b81FWGIR0f1Cr2MeDiOQ2pty24dKK LUqIhogTZdFAN0ed6Ktc82/5xBoH1gv7YeqyPBJvAxW6ekMsgOEzLq9OU3ESezZorYFdrQTzqsEXUp1A+cZdfo 0eKwZTFmjNAsh1kis+HOLoQQwyjgaxYI= -----END NEW CERTIFICATE REQUEST-----

The CSR is written in as a text file to the <PS_HOME>\webserv\peoplesoft directory. The file name is <host_name>_certreq.txt.

Submitting CSRs to CAs for Signing (WebLogic)

After you generate the private key and a certificate signing request (CSR), you must submit the CSR to the certificate authority (CA) for signing.

The process of obtaining the signature varies, depending on the CA that you select. Typically, a CA requires you to paste the content of the PEM-formatted CSR into a form that you submit online. However, the CA may send the signed public key (root) certificate to you by email or require you to download it from a specified web page. The CA may also provide its root certificate or instructions for retrieving it.

Use the appropriate method to submit a CSR for signing as determined by your CA.

When you do submit the CSR for signing the content you provide must include the begin section
(-----BEGIN NEW CERTIFICATE REQUEST-----) and the end section (-----END NEW CERTIFICATE REQUEST-----) of the CSR.

The CA will return the signed certificate to you that you must import into the keystore.

Importing Signed Private Keys into Keystores (WebLogic)

You use PSKeyManager to import a server-side private key into the keystore.

Open PSKeyManager.
1. Open a command prompt and navigate to <PS_HOME>\webserv\<domain>.
2. Enter the following at the prompt:
```
pskeymanager -import
```
3. At the Enter current keystore password prompt, enter the password and press Enter.
At the Specify an alias for this certificate prompt, enter the alias name and press Enter.

The alias name you enter must be the same one you entered when you generated the private key.
At the Enter the name of the certificate file to import prompt, enter the path and name of the certificate to import, and press Enter.
At the Trust this certificate prompt, enter Yes and press Enter.

Setting Up Gateway Private Keys (WebLogic)

To set up private keys for gateways, follow the procedures outlined in the following topics presented earlier in this section:

Generating Private Keys and CSRs.
Submitting CSRs to CAs for Signing.
Importing Server-Side Private Keys into Keystores.

The only difference is that for the following prompts you enter names that are gateway-specific:

Prompt	Sample Values
Certificate alias.	Enter an alias, such as PT845GATEWAY.
Common name for this certificate.	Enter a name, such as PT845GATEWAY.

Setting Up BEA WebLogic for SSL

To set up BEA WebLogic for SSL:

Login to WebLogic Console.
1. Open a web browser.
2. In the URL or address field, enter http://localhost/index.html and press Enter. The BEA WebLogic Server 8.1 Web Server Index Page displays.
3. Click Access WebLogic Server Console. The signon page for WebLogic Server Administration Console appears.
4. Enter the Username and Password and click Sign In. WebLogic Administration Console displays.
  
  The username and password are those that you specified when you installed PeopleSoft Pure Internet Architecture.
Navigate to the PIA server Configuration page.
- In the WebLogic Server Console In the left navigation area, navigate to PeopleSoft, Servers, PIA. Or,
- In the WebLogic Server Console, in the Domain Configuration section, click Servers. The Servers page displays. In the table that appears on the page, click the PIA link.
Click the Keystores and SSL tab.
In the Keystore Configuration section, on the right side of the page, click the Change link. The Specify Keystore Type page displays.
From the Keystores drop-down list, select Custom Identity and Custom Trust.
Click the Continue button. The Configure Keystore Properties page displays.
In the Custom Identity section complete the following fields:
1. In the Custom Identity Key Store File Name field, enter keystore/pskey.
2. In the Custom Identity Key Store Type field, enter JKS.
3. In the Custom Identity Key Store Pass Phrase field, enter password.
4. In the Confirm Custom Identity Key Store Pass Phrase field, enter password again.
5. Click the Continue button. The Review SSL Private Key Settings page displays.
In the Review SSL Private Key Setting page, review the information and click the Continue button.
Click the Finish button. You will restart the web server at a later time. You are returned to the Keystore Configuration tab.
Scroll down the page to the Advanced Options section and click the Show link.
In the Server Attributes section, from the Two Way Client Cert Behavior drop-down list, select Client Certs Requested and Enforced.
Click the Apply button.
Restart the web server.

Installing Digital Certificates for Server Authentication SSL on IBM WebSphere

This section describes how to install digital certificates for server authentication SSL for the IBM WebSphere environment and discusses how to:

Generate and import public keys.
Generate private keys and CSRs.
Submit CSRs to CAs for signing.
Import signed private keys into keystores.
Set up gateway private keys.
Set up IBM WebSphere for SSL.

Generating and Importing Public Keys (WebSphere)

To generate and import a root certificate:

From the Key Database File menu, select Open PSKEY. The location is:

PS_HOME\webserv\<cell_name>_<node_name>_<server_name>\peoplesoft.ear\keystore\pskey

Click the Download button and load the file to <PS_HOME>\webserv\<DOMAIN>. For example:
```
<PS_HOME>\webserv\<DOMAIN>\<host_name>_PeopleTools.cer
```
In the Password field, enter password.
In the Key Database Content section, from the drop-down list select Signer Certificates.
Click the Add button to add a CA certificate.
Enter the following values:
1. In the Data Type field, select or enter Binary DER data.
2. In the Certificate File Name field, enter <host_name>_PeopleTools.cer.
3. In the Location field, specify <WAS_HOME>\ssl.
Click the OK button and select a label.

Generating Private Keys and CSRs (WebSphere)

To generate private keys in IBM WebSphere you use IBM Key Management.

To generate server-side private keys and CSRs:

Open IBM Key Management.
1. Open a command prompt and navigate to <WEBSPHERE_HOME>\appserver\bin.
2. At the prompt, enter the following:
```
Ikeyman
```
3. Press the Enter key. IBM Key Management opens.

Select Key Database File, Open PSKEY.

The location is:

<PS_HOME>\webserv\<cell_name>_<node_name>_<server_name>\peoplesoft.ear\keystore\pskey

Enter the password.
In the Key Database Content section, from the drop-down list select Personal Certificate Requests.
Click the New button. The Create New Key Certificate Request window opens

Enter the appropriate information in the following required fields:

Key Label	Enter the host name.
Key Size	From the drop-down list select 1024.
Common Name	Enter the host name for the certificate. For example: <host_name>.corp.peoplesoft.com
Organization	Enter the organization name.

In the Enter the name of a file in which to store the certificate request field, enter the location in Step 2.
Click the OK button. The window closes.

In the Key Database Content section, the key label appears under the Personal Certificate Requests section.

IBM Key Management generates and writes the private key to <WAS_HOME>\ssl\certreq.arm.

Submitting CSRs to CAs for Signing (WebSphere)

After you generate the private key and a certificate signing request (CSR), you must submit the CSR to the certificate authority (CA) for signing.

The process of obtaining the signature varies, depending on the CA that you select. Typically, a CA requires you to paste the content of the PEM-formatted CSR into a form that you submit online. However, the CA may send the signed public key certificate to you by email or require you to download it from a specified web page. The CA may also provide its root certificate or instructions for retrieving it.

Use the appropriate method for submitting a CSR for signing as determined by your CA.

When you do submit the CSR for signing the content you provide must include the begin section
(-----BEGIN NEW CERTIFICATE REQUEST-----) and end section (-----END NEW CERTIFICATE REQUEST-----) of the CSR.

The CA will return the signed certificate to you.

Importing Signed Public Keys into Keystores (WebSphere)

After you receive a signed certificate back from the CA, you must import it into the keystore.

To import server-side public keys into keystores:

Open IBM Key Management.
1. Open a command prompt and navigate to <WEBSPHERE_HOME>\appserver\bin.
2. At the prompt, enter the following:
```
Ikeyman
```
3. Press the Enter key. IBM Key Management opens.
In the Key Database Content section, from the drop-down list select Personal Certificates.
Click the Receive button. The Receive Certificate from a File box displays.
From the Data Type drop-down list, select Base64-encoded ASCII Data.
In the Certificate File Name field enter the name of the certificate to import or click the Browse button to locate the file.
In the Location field, enter the path to the certificate file.
Click the OK button.

The Receive Certificate from a File box closes and the name of the certificate appears in the Personal Certificates section in IBM Key Management.

Setting Up Gateway Private Keys (WebSphere)

To set up private keys for gateways, follow the procedures outlined in the following topics presented earlier in this section:

Generating Private Keys and CSRs
Submitting CSRs to CAs for Signing
Importing Server-Side Private Keys into Keystores

The only difference is that for the following prompts you enter names that are gateway-specific:

Prompt	Sample Values
Certificate alias.	Enter an alias, such as PT845GATEWAY.
Common name for this certificate.	Enter a name, such as PT845GATEWAY.

Setting Up IBM WebSphere for SSL

Setting up IBM WebSphere for SSL requires that you perform the following tasks:

Configure SSL repertoires.
Set up WebSphere servers for SSL.
Set up inbound Common Secure Interoperability (CSI) authentication.

To configure an SSL repertoire:

Start the WebSphere Administration Console.

The URL is http://localhost:9090/admin/.
In the left navigation area, navigate to Security, SSL. The SSL Repertories page displays.
Click the New button. The SSL Configuration Repertoires page displays.
On the Configuration tab, enter values for the following fields:
1. In the Alias field enter Web Container SSL.
2. In the Key File Name field enter the location of the JKS file or the location of PSKey. For example:
```
<PS_HOME>\webserv\<cell_name>_<node_name>_<server_name>\peoplesoft.ear\keystore\pskey
```
3. In the Key File Password field, enter the keystore password.
4. In the Key File Format field, enter JKS.
5. In the Trust File Name field, enter the location of the location of the JKS file or the location of PSKey.
6. In the Trust File Password field, enter the certificate password.
7. In the Trust File Format field, enter JKS.
8. Clear the Client Authentication box, if selected.
9. In the Security Level field, select High.
10. Click OK.
Save the configuration.

To set up a WebSphere server for SSL:

Open the WebSphere Administration Console, if it is not already open.

The URL is http://localhost:9090/admin/.
In the left navigation area, select Servers, Application Servers and select the server with which you would like to work. The Application Servers page displays.
Click the name of the server that appears as a hyperlink on the page.
Click the Configuration tab.
In the Additional Properties section, click Web Container. The Web Container page displays.
In the Additional Properties section, click the HTTP Transports link.
Check the box of the row that contains the entry for the transfer you want to secure.
In the Hosts column click the asterisk (*). The HTTP Transports page displays.
In the Configuration panel in the General Properties section, for the SSL Enabled property check the Enable SSL box.
From the SSL drop-down list, select the desired SSL entry from the repertoire.
Click the OK button and save the changes.

To set up CSI authentication:

Open the WebSphere Administration Console, if it is not already open.

The URL is http://localhost:9090/admin/.
In the left navigation area, navigate to Security, AuthenticationProtocol, CSIV2InboundAuthentication. The CSI Authentication ->Inbound page displays.
For Basic Authentication, select Supported.
For Client Certificate Authentication, select Required.
Save the changes and reboot the web server.

Setting Up Digital Certificates for Server Authentication on Application Servers

This section discusses how to set up server-side digital certificates on an application server and describes how to:

Add CA authorities and root certificates.
Set up local node certificates.
Set up remote node certificates.

Adding CA Authorities and Root Certificates

PeopleSoft delivers a number of root certificates, before you begin this process, check to see if your root certificate already exists. If it does, there is no need to perform this step.

If your root certificate does not exist, contact your CA for information on how to obtain the root certificate for importing into PeopleSoft.

To add CA authorities and root certificates:

Select PeopleTools, Security, Security Objects, Digital Certificates. The Digital Certificates page displays.
Add a CA authority:
1. Click the plus button (+). A new row appears.
2. From the Type drop-down list, select Root CA.
3. In the Alias field, enter the alias name for the certificate.
4. In the Issuer Alias field, enter an alias for the issuer. Click the Lookup button to select the certificate alias as the issuer alias.
Add the root certificate.
Click the Add Root link near the plus button (+). The Add Root Certificate page displays.
Copy the contents of the certificate into the text box.

You must include the begin section (-----BEGIN CERTIFICATE-----) and end section
(-----END CERTIFICATE -----).
Click the OK button.
Click the Refresh button.

Setting Up Local Node Certificates

This section discusses setting up local node client certificates and discusses how to:

Add local node certificates to the PeopleSoft system and generate CSRs.
Submit local node certificates to CAs for signing.
Import signed local node certificates into the PeopleSoft system.

To add a local node certificate and generate a CSR:

Select PeopleTools, Security, Security Objects, Digital Certificates. The Digital Certificates page displays.
Click the plus button (+). A new row appears.
1. From the Type drop-down list, select Local Node.
2. In the Alias field, enter the name of the local node.
  
  Do not include any underscores (_) in the node name you enter. For example, if the node name is QE_LOCAL, enter QELOCAL.
3. In the Issuer Alias field, click the Lookup button to select the issuer alias.
At the end of the row, click the Request link. The Request New Certificate page displays.

In the Subject Information section, enter the following information:

Company Name.	Enter the default local node name (with no underscore).
Org Unit(organizational unit)	Enter the name of the organizational unit.
Organization	Enter the name of the organization.
Locality	Enter the location of the organization.
State/Province	Enter the state or province name.
Country	Enter the two-character country code.

In the Key Pair Information section, enter the following information:
1. From the Algorithm drop-down list, select MD5 with RSA Encryption.
2. From the Key Size drop-down list, select 1024.
Click the OK button.

To submit a local node certificate for signing:

After you click the OK button as described in the previous section, the CSR is generated. Copy the CSR and submit it to your CA for signing.

When you submit the CSR for signing, you must include the begin section (-----BEGIN NEW CERTIFICATE REQUEST-----) and the end section (-----END NEW CERTIFICATE REQUEST-----).
When you receive the signed certificate back, copy it to a temporary directory. For example:
```
c:\temp\newcert.cer
```

After you generate a CSR for the local node certificate and obtain a signature, you import the signed certificate into PeopleSoft.

To import signed local node certificates into a PeopleSoft system:

Select PeopleTools, Security, Security Objects, Digital Certificates. The Digital Certificates page displays.
Locate the row that contains the local node certificate.
At the end of the row, click the Import link. The Import Certificate page displays.
Open the signed certificate you received back from the CA, copy it and paste it into the text box. The content you paste must include the begin section (-----BEGIN CERTIFICATE-----) and end section (-----END CERTIFICATE-----).
Click the OK button.
Click the Refresh button.

Setting Up Remote Node Certificates

To section discusses setting up remote node certificates and describes how to:

Export remote node certificates.
Add remote node CAs and import remote certificates into the local node system.

To export a remote node certificate:

On the remote node system, select PeopleTools, Security, Security Objects, Certificates. The Digital Certificates page displays.
Locate the row that contains the default local node, and click the Detail link at the end of the row. The Certificate Details page displays.
Click the Export button and copy the content in the edit box.
Click Cancel.

To add a remote node CA and import a remote node certificate into the local node system:

On the local node system, select PeopleTools, Security, Security Objects, Certificates. The Digital Certificates page displays.
Click the plus button (+). A new row appears.
1. From the Type drop-down list, select Remote Node.
2. In the Alias field, enter the name of the remote node.
  
  Do not include any underscores (_) in the node name you enter. For example, if the node name is QE_REMOTE, enter QEREMOTE.
3. In the Issuer Alias field, click the Lookup button to select the issuer alias.
Click the Refresh button.
At the end of the remote node row, click the Import link. The Import Certificate page displays.
Paste the certificate that you exported in the previous section into the text box. You must include the begin section (-----BEGIN CERTIFICATE-----) and the end section (-----END CERTIFICATE-----).
Click the OK button.
Click the Refresh button.

Installing Digital Certificates for Client Authentication SSL

This section discusses installing digital certificates for client authentication SSL and discusses how to:

Generate private and public key pairs.
Generate CSRs.
Obtain signed root certificates.
Import signed root certificates.

Understanding Installing Digital Certificates for Client Authentication SSL

You use the Java-based Keytool command line utility to install gateway-based certificates for SSL with client authentication, which secures outbound messages. The integration gateway requires the following elements:

The gateway's private key.
A certificate containing the gateway's public key, digitally signed by a trusted CA.
A root certificate from the CA that signed the gateway's public key.

With Keytool, you generate a private-public key pair, which is automatically inserted in a gateway keystore that in created with the PeopleSoft Pure Internet Architecture installation in the web server directory structure.

The location of Keytool is <PS_HOME>\webserv\<DOMAIN>\keystore\.

You generate a PEM-formatted CSR that contains the gateway's public key. You submit the CSR to the selected CA. The CA creates, digitally signs, and returns your gateway's public key certificate to you. This certificate also contains a signed copy of the CA's root certificate. These certificates may be in standard DER-encoded binary format, or they can be converted to PEM format if necessary.

You then install both signed certificates in the gateway keystore. In addition, you register them and the private key with the web server so that it can recognize and use them.

Understanding the Keytool Utility

You may have previously installed software on the gateway server machine that included a distribution of the Keytool utility. To install client authentication SSL for PeopleSoft Integration Broker, be sure to use a copy of Keytool that was provided as part of the Java Runtime Environment (JRE).

Use the copy of Keytool that was installed with either the PeopleTools application server or the web server. You can find Keytool in <PS_HOME>\jre\bin.

You can also find it in the web server directory structure by searching for Keytool.exe (Windows) or keytool.sh (UNIX). The basic syntax of Keytool is as follows:

keytool -command

Each command can be followed by a variety of options. Both the command and the keyword for each option that you invoke with it must be preceded by a hyphen, and most options must be followed by a value. If you enter keytool alone, a list of all commands and their options is displayed. Keytool provides more than a dozen commands, but you'll use only a few for this task:

keytool -genkey keytool -certreq keytool -import

This section outlines only the basic steps required to install the certificates and keys that you need. You can obtain complete documentation for Keytool from Sun Microsystems.

See http://java.sun.com

Generating Private and Public Key Pairs

To generate a key pair:

Open a command prompt and navigate to the location of gateway keystore file.

The location is <PS_HOME>\webserv\<DOMAIN>\keystore

Issue the following command (substituting the appropriate path for Keytool, if necessary):

PeopleTools_home\jre\bin\keytool -genkey -alias key_alias -keyalg RSA -keysize keysize -dname "CN=cName, OU=orgUnit, O=org,
L=locality, ST=state, C=country" -keypass key_password -keystore pskey -storepass password

Provide values for the options as follows:

Option	Specify a name for the key pair; for example, My_GW_Client_Key. You also enter this value in the integrationGateway.properties file.
keysize	Specify one of the following values for the key size: 1024: This specifies a 1024-bit key, which provides 128-bit encryption. This is the default value. 512: This specifies a 512-bit key, which provides 40-bit encryption.
dname "CN=cName, OU=orgUnit, O=org, L=locality, ST=state, C=country"	Specify the gateway's DN attributes. The DN attributes are name-value pairs separated by commas and spaces, and they are enclosed in quotes as a single string. If a value includes a comma, you must precede the comma with a backslash escape character; for example: O=PeopleSoft\, Inc., You must supply the DN attributes in the order shown. Although their values can be arbitrary, you should supply the appropriate real-world information.
key_password	Enter a password of your choice for the key pair. It must be at least six characters long. You also enter this value in the integrationGateway.properties file.

The key pair is generated and must be imported into the keystore. Use the steps described earlier in this chapter for importing private keys into keystores for the web server you are using to import the keypair into the keystore.

Generating CSRs

While you are at the command line in the gateway keystore directory, issue the following command:

PeopleTools_home\jre\bin\keytool -certreq -alias key_alias -file csr_filename -keypass key_password -keystore pskey -storepass password

Provide values for the options as follows:

key_alias

Enter the name of the key pair that you created previously; for example:

My_GW_Client_Key

csr_filename

Specify the name of the file that contain the CSR; for example:

My_GW_Client_Key.csr

You can also include a path for the file to create it in a different location than the keystore.

key_password

Enter the password that you specified when you created the key pair.

The CSR file appears in the location and with the name that you specified.

Obtaining Signed Root Certificates

You need to obtain a signed certificate from the selected CA. The signed certificate contains your gateway's public key. The process of obtaining digital certificates varies, depending on the certificate authority that you select. Typically, a CA requires you to paste the content of the PEM-formatted CSR into a form that you submit online. The CA may send you the signed public key certificate by email, or it may require you to download the certificate from a specified page. The CA may also provide its root certificate or instructions for retrieving it. Save the certificates to the location of the keystore file in the following location:

<PS_HOME>\webserv\<DOMAIN>\keystore

Importing Signed Root Certificates

The public key certificate includes more than a single client certificate; the same file contains the issuing CA's root certificate as well. If you do not receive a separate root certificate from the CA, you must export it from the public key certificate.

To import signed root certificates:

Open a command prompt and navigate to the gateway keystore file.

The location is <PS_HOME>\webserv\<DOMAIN>\keystore

Issue the following command (substituting the appropriate path for Keytool, if necessary):

<PS_HOME>\jre\bin\keytool -import -trustcacerts -alias root_cert_alias -file root_cert_filename -keystore pskey -storepass
password

This command imports the signed root certificate into the gateway keystore. Provide values for the options as follows:

root_cert_alias

Specify the alias to use on your gateway to refer to the root certificate; for example:

"Root SGC Authority"

root_cert_filename

Enter the name of the root certificate file that you received from the CA or exported from the public key certificate; for example:

"Root SGC Authority.cer"

While at the command line in the gateway keystore directory, issue the following command:

<PS_HOME>\jre\bin\keytool -import -alias key_alias -file client_cert_filename -keypass key_password -keystore pskey -storepass
password

This command imports the signed public key certificate into the gateway keystore. Provide values for the options as follows:

key_alias

Enter the name of the key pair that you created previously, for example:

My_GW_Client_Key

client_cert_filename

Specify the name of the newly received public key certificate; for example:

My_GW_Client_Key.cer

key_password

Enter the password that you specified when you created the key pair.

Configuring SSL Encryption

Configuring SSL encryption involves the following tasks:

Supply the digital certificates containing the public and private keys required for encrypted transactions. You install these certificates in both the web server keystore and the gateway keystore. You configure the web server to recognize and use its installed certificates for SSL transactions.

See Installing Digital Certificates for Server Authentication SSL on BEA WebLogic, Installing Digital Certificates for Server Authentication SSL on IBM WebSphere, Installing Digital Certificates for Client Authentication SSL.
Edit the Integration Gateway Certificates section of the integrationGateway.properties file to convey parameters for the server certificates that you installed in the gateway keystore.

Integration Gateway Properties File Parameter

Description

ig.certificateAlias

Certificate alias.

ig.certificatePassword

Certificate alias password.

See Using the integrationGateway.properties File.

Integration Gateway Properties File Parameter	Description
ig.certificateAlias	Certificate alias.
ig.certificatePassword	Certificate alias password.

After the appropriate server certificates are installed and configured, the gateway can send and receive secure messages. However, to invoke the secure SSL connection, messages must be directed to an HTTPS URL. To enable outgoing HTTPS, you must change the value of the HTTP target connector's PRIMARYURL;URL property to start with https:// instead of http://. You can apply this setting on a node by node basis, or apply it to the gateway as a whole, which will use it as the default setting for all nodes. The HTTP target connector makes the necessary SSL connection at runtime.

Receipt of HTTPS requests is nearly automatic. When the integration gateway's HTTP listening connector receives an HTTPS request, it is forwarded to the default local node for authentication.