Installing Application Server-Based Digital Certificates

Adding CA Authorities and Installing 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 install a new root CA certificate:

Select PeopleTools, and then Security, and then Security Objects, and then Manage 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.

Install Signed Public Key Certificates for Application Server-Based Digital Certificates

To section 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 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 add a local node certificate and generate a CSR:

Select PeopleTools, and then Security, and then Security Objects, and then Manage 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.
  
  Note:
  
  The name you enter must exactly match the name of the local node.
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:

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 the fields. The DN is also 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.

Field or Control	Description
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, from the Algorithm drop-down list, select a value. The values are:
- MD5 with RSA encryption.
- SHA1 with DSA encryption.
- SHA1 with RSA encryption. (Default.)
- SHA256 with RSA encryption.
From the Key Size drop-down list, select a key size (bits):.
- 1024. (Default.)
- 2048.
- 4096
- 768.
- 512.
Click the OK button.

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.

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.

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.

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, and then Security, and then Security Objects, and then Manage Digital Certificates. The Digital Certificates page displays.
Locate the row that contains the local 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.

Three outcomes are possible:

The Digital Certificates page appears 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.
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.
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 certificate in your keystore must be accompanied by a root CA certificate signed by the same CA.

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 for Application Server-Based Digital Certificates

To section discusses setting up remote certificates for nonrepudiation and certificated-based node authentication and describes how to:

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

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.

Note:

Each remote certificate is a copy of the local node certificate and is installed on the remote node that it represents. As a result, 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.

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 export a remote node certificate:

On the remote node system, select PeopleTools, and then Security, and then Security Objects, and then Manage Digital 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, and then Security, and then Security Objects, and then Manage Digital 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.
  
  Note:
  
  The name you enter must exactly match the name of the remote node.
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.