SSL Implementation-Peoplesoft

SSL Implementation-Peoplesoft

SSL Handshake- Simple explanation

1.The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.

2.The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number. The server also sends digital certificate which contains server’s public key.

Note: The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.

3.The server sends its digital certificate and this contains servers public key If the server uses SSL V3, and if the server application (for example, the Web server) requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.

4.The server sends a server "hello done" message and waits for a client response.

5.Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable.

If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory.

6.The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server.

If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.

Note :An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.

7.The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys.

8.The server responds with a "change cipher spec" and a "finished" message of its own.

9.The SSL handshake ends, and encrypted application data can be sent.

How SSL can be configured in Peoplesoft

What all we need for SSL in Peoplesoft?

1.      Webserver’s private key

2.      The web server's public key, digitally signed by a trusted certificate authority (CA), like verisign.

3.      The digitally signed public key of the same CA that signed the web server's key

A public key is transferred and stored as a data element in a digital certificate or a certificate signing request (CSR). You can obtain public keys from a variety of sources in several different formats.

When setting up SSL, you need to:

• ensure that the encryption keys are correctly formatted.
• install them in the keystore.
• configure them using the Administration Console

Generate new key and CSR:

In PT8.49/PT8.50 as in prior versions of PeopleTools, we use pskeymanager to facilitate the SSL setup. This script is located under the following directory:
For PT8.49/8.50: <PS_HOME>/webserv/<DOMAIN>/bin.
For PT8.51: <PS_HOME>/webserv/<DOMAIN>/piabin

4. Generate key using pskeymanager –createm (For usage information, enter pskeymanager -help.)
5. Follow the prompts and enter the requested information to create a new private key and a CSR for your web server.
1. Pskeymanager uses the keystore in PIA_HOME\webserv\domain_name\keystore\pskey, with a default password of password.
2. Pskeymanager prompts you for an alias for the new keys, for example, ServerABC. This is the name you'll use to refer to the keys in the future.
3. Pskeymanager prompts you for distinguished name fields. Enter the appropriate values for your organization.
4. Pskeymanager prompts you for information about the CSR expiration date, key size, key algorithms, and the private key password. All of these fields have default values.

Pskeymanager creates the private key inside the keystore, and creates the CSR as a file called ServerABC_certreq.txt in the current directory. You use the CSR (certificate signing request) to obtain your signed public key certificate and a root certificate from a CA.

4. Submit the new CSR to your Certification Authority, a.k.a. CA (they will issue a new certificate for your     server). The process may slightly change depending on which CA you selected. I continue the process taking Verisign as an example. In your organizations you will have different CAs.
5. Open your CSR file in a text editor and copy its entire contents, including the first and last lines:

-----BEGIN NEW CERTIFICATE REQUEST-----

...

...

-----END NEW CERTIFICATE REQUEST-----

5.      Access Verisign's test certificate enrollment site at https://www.verisign.com/ssl/buy-ssl-certificates/free-ssl-certificate-trial/index.html.

Verisign guides you through the CSR submission process, including:

1. Accepting the Verisign license agreement.
2. Entering your technical contact information, which includes the email address where Verisign can send your signed public key.
3. Pasting your CSR contents in the provided text field.
4. Verifying your CSR.
5. Confirming and submitting your order.

Verisign also provides its own digitally signed public key in a certificate, which is known as a trusted CA certificate, a root certificate, or a chain certificate.

6.      Download the VeriSign test CA root certificate from http://digitalid.verisign.com/cgi-bin/getcacert.

When prompted, save getcacert.cer to PIA_HOME\webserv\domain_name.

7.      Check your email.

Verisign digitally signs your web server's public key, then returns it to you in a certificate, called the server certificate. Following is an example of the contents of a server certificate:

8.      Copy the entire certificate contents, and save it as a text file called ServerABC-cert.pem in PIA_HOME\webserv\domain_name.

Be sure to include the first and last lines.If you need to FTP the file to a unix box make sure to use ASCII mode.

9.      Once you have the 2 files (root CA and certificate) edit root CA and do a <Select All>, and then <Copy>. Then edit your certificate file and paste the rootCA contents at the bottom of the server certificate. Certificate file will look like this.

-------BEGIN CERTIFICATE---------
dfsfsdfdf
sfsdfwehdfhdf <---------certificate
dgdfgfgfdg
--------END CERTIFICATE-----------
-------BEGIN CERTIFICATE---------
hghjgfjgj
sfsdfwejjhdfhdf <---------intermediate
dgdfgiuiyuiuiyufgfdg
--------END CERTIFICATE-----------

(Your server certificate must contain, in addition to the web server's public key, any keys necessary to establish a chain of trust that culminates in the self-signed root certificate of a trusted root CA. That CA's root certificate must be in the keystore of any browser that's used to access your web server. Most browsers have an extensive set of trusted root certificates in their keystores.)

10.  Import the Root CA first:
pskeymanager -import
When prompted for an Alias, enter anything, such as RootCA
When prompted for the name of the certificate file, enter RootCA.cer
If asked if you want to trust this file, say yes.

11.   Import the server certificate (concatenated file):
pskeymanager -import
When prompted for an Alias, enter the same alias you specified when you created the CSR (step 3 of the above section).
When prompted for the name of the certificate file
When prompted for the key password, enter the password you specified when you created the key/CSR (this password is unrecoverable)
If asked if you want to trust this file, say yes.

12.   Setup SSL in the Admin Console: -weblogic console

Log into the Admin Console: http://hostname:admin_port/console
On the Change Center:
Lock and Edit
Go to:
Domain Structure <Environments> Servers
Click on PIA or the server you want to configure for SSL.
Go to the "Keystores" tab.
Select 'Custom Identity And Custom Trust' from the Keystores dropdown field
Verify that the Custom Identity and Trust keystore and password are correct. The default pskey keystore is "password"
Click on the "Save" button.
Go to the "SSL" tab
Select "Keystores" from the "Identity and Trust Locations" dropdown field
Enter the Private Key Alias: same alias as in the step 3 of the "Generate new key" section..
Enter the Private Key Password: same password as in the step 3 of the "Generate new key" section..
Click on the "Save" button.
Activate Changes.
Restart the Web Server.