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
- Generate key using pskeymanager –createm (For usage information, enter
pskeymanager -help.)
- Follow the prompts and enter
the requested information to create a new private key and a CSR for your
web server.
- Pskeymanager
uses the keystore in PIA_HOME\webserv\domain_name\keystore\pskey,
with a default password of password.
- 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.
- Pskeymanager
prompts you for distinguished name fields. Enter the appropriate values
for your organization.
- 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.
- 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.
- 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:
- Accepting
the Verisign license agreement.
- Entering
your technical contact information, which includes the email address
where Verisign can send your signed public key.
- Pasting
your CSR contents in the provided text field.
- Verifying
your CSR.
- 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.
