Secure Socket Layer (SSL) and web server certificates are two of the most important components for a secured web communication. While those two components are pivotal to a secured PeopleSoft implementation, the knowledge and complete understanding remains nebulous to many PeopleSoft Administrator. On today's entry, I'll try to shed some light on the basic concepts of SSL and certificates on Weblogic web servers.
What is SSL ?
Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers (Wikipedia).
SSL was created by Netscape to ensure transaction between web servers and browsers. The protocol uses a third-party usually called a Certificate Authority (CA), to identify one end or both end of the transaction. Below summarizes the follow of communication between the browser and the web server.
1. A browser requests a secure page usually sent with the following URL - https://
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
5. The web server decrypts the encryption key using its private key and uses the key to decrypt the URL and http data.
6. The web server sends back the requested html document and http data encrypted with the key.
7. The browser decrypts the http data and html document using the key and displays the information.
Basic SSL Terminologies
Private Key/Public Key - These are encryption key pairs that ensures that data encrypted by one key can be decrypted by other key. The key pairs resides on both the browser and the web server.
Certificates - A certificate contains all the elements used to send an encrypted message to the owner (using the public key) or to verify a message signed by the author of this certificate. These elements include:
• reference to the issuer
• information about the owner
• certificate usage
• duration of validity
• resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage)
• the certificate ID of the person who certifies (signs) this information
• public key
• a hash (signature) to ensure that the certificate has not been tampered with
There are two types of certificates; Root Certificate which is usually signed by your Certificate Authority (CA) and the Intermediate Certificate. Depending on your Certificate Authority (CA), the Intermediate Certificate might not be provided. The Intermediate Certificate provides an additional layer of security to secured communication. Usually your browser and your web server already has Root Certificates of well known Certificate Authorities (CA) preloaded on your application. The CA maintains a list of signed certificates as well as revoked certificates. A certificate is insecured until it is signed by a CA.
Now that we've been exposed to the key concepts of SSL and Certificates, let's walk-thru updating an expired SSL Certificate in Weblogic Web Servers. Updating a certificate in Weblogic is almost the same as requesting a new certificate except for the latter (Update), which doesn't require you to delete expired certs. The following steps describes how to update an expired certificate in Weblogic.
I. Delete expired certificate from your keystore
Use the following command to delete expired certificate from your keystore:
Pskeymanager.sh –delete –v –alias test
(where test is the alias for the cert you want deleted)
http://i3.tinypic.com/869rckz.jpg
II. Generate a CSR on the web server and use it to generate a corresponding public key on the Certificate Authority’s web site.
To decrypt SSL request, it requires that you have a corresponding private key on your web server. You generate a private key and send it to the certificate authority (Verisign) to generate a corresponding public key /Trusted Certificate based on your private key information. To generate a private key, enter the following command on the web server command line and follow the prompt: pskeymanager.sh –create –alias myprivatekey
http://i8.tinypic.com/6tm60qu.jpg
http://i11.tinypic.com/6toj0pw.jpg
http://i15.tinypic.com/6ybu45x.jpg
III. Import the intermediate (Root CA) into your keystore via pskeymanager utitlity.
Go to the following link to obtain intermediate/Root CA from Verisign - http://www.verisign.com/support/verisign-intermediate-ca/secure-site-pro-intermediate/index.html . In this case, we are using Verisign as our CA.
Download the Intermediate certificate (Verisign requires that we obtain the Intermediate Certificate as well). When prompted, save as Intermediate.cer and FTP it in ASCII mode to your Weblogic domain directory. Execute the following command at the prompt to import the Intermediate certificate into your keystore :
Pskeymanager.sh –import -trustcacerts
http://i13.tinypic.com/86e4g1h.jpg
When prompted for an alias, specify VerisignTestCA as the name to store this CA as. This is simply an alias for this certificate. You can use any alias you want. When prompted for the certificate file to import, specify the Intermediate.cer file.
IV. Import the public key (certificate) you get from the certificate authority (Verisign) into your keystore via pskeymanager utility
When you receive your certificate via email from the certificate authority (Verisign), you will see your actual certificate in the following format :
-----BEGIN CERTIFICATE-----
MIIEvzCCBCigAwIBAgIQUhoVSb+AwOsuKn38CdU19TANBgkqhkiG9w0BAQUFADCB
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0w
0dHA6Ly9TVlJJbnRsLWFpYS52ZXJpc2lnbi5jb20vU1ZSSW50bC1haWEuY2Vy
MG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4D
AhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWdu
LmNvbS92c2xvZ28xLmdpZjANBgkqhkiG9w0BAQUFAAOBgQDFnyR7Xlsgbag97HqJ
mY+uIVhZunbymctkZ70789jEJzBKLTl+BRjpdYodu3DiOLLmusus2BJwTbMLBenk
dNKF11VHYTrrenNJCSkc6fzXJlG/jMUtSpbhUAmZxIcmRUst4UGaKF/PrAseT1ad
tA0KvM1DwTn/z+g6Ofw1QuDbJA==
-----END CERTIFICATE-----
A. Copy the certificate information, including - -BEGIN CERTIFICATE- - and - - END CERTIFICATE - - and save it as text file called
B. Import your certificate into your keystore:
To import your public certificate, execute the following at the prompt “pskeymanager.sh – import -trustcacerts”
http://i13.tinypic.com/86e4g1h.jpg
When prompted for password, enter ‘password’. When prompted for an alias specify the same alias you entered when you generated the CSR. It is very important that you match the alias otherwise the import would fail.
When prompted for the certificate file to import, specify your certificate file in step 1
C. Bounce the web server.
D. Verify that the certificate is in the keystore by entering this command at the prompt ‘pskeymanager.sh – list – alias myprivatekey’
To preview and verify the expiration date of your certificate, use the ‘ previewfilecert –file
V. Reconfigure Keystore/SSL on the Weblogic console.
Log into the weblogic administration console (http://machinename:port/console) and navigate the following path – Servers > PIA > Keystores & SSL
http://i7.tinypic.com/6tn8ewk.jpg
· Scroll down to the SSL Configuration section and verify the ‘Private Key Alias’ is the same as the name you specified when you created the CSR in step II, otherwise change it to match the alias. The ‘Passphrase’ field should be the same as keystore password when SSL was initially created (default password is ‘password’). Reenter the password to be sure you’re reconfiguring with the same password in the keystore. If password doesn’t match the password in the keystore, you will get ‘Cannot read private key’ error message and SSL port will not be listening when you reboot the server.
http://i9.tinypic.com/85kz7no.jpg
· Click on the ‘Change’ hyperlink to specify where to find the private key you created in step II. Remember that you need private key, public key and Intermediate certificate (a.k.a Trusted CA, Root CA, Chain Certificate) obtained from the certificate authority (Verisign) to complete a handshake SSL request. You can either manage these keys (private and intermediate) on file or let the keystore automatically manage them. When you manage these keys on file, identity and trust locations field on the SSL section of the web console should be changed to ‘Files or Key Stores Providers’. This type of key management would put explicit names and locations for the keys in the config.xml file. Make sure the files exist at the location specified in the config.xml file. These are the entries on the SSL section of config.xml file : Server CertificateFileName (public key), ServerKeyFileName (private key), TrustedCAFileName (intermediate). Click continue, log off the web console and bounce the web server.
http://i5.tinypic.com/81zmu7t.jpg
When you manage these key files automatically, identity and trust location field on the SSL section of the web console should be changed to ‘Key Stores’. This type of key management instructs weblogic to find private and intermediate key files on the keystore. You don’t have to explicitly define the locations for these key files. Click continue, log off the web console and bounce the web server.
http://i7.tinypic.com/86rcaom.jpg
Log on to the secured site to verify SSL has been updated. Double click on the padlock icon at the bottom of the browser and verify “Issued to” and “Issued by” on the General tab. Also verify the certificate chain by clicking on the Certification Path tab. The chain should be in this pattern – Verisign Class 3 Public Primary CA (Root CA) è www.verisign.com/CPS Incorp. by Ref. LIABILITY LTD.(c)verisign (Intermediate CA) è 
http://i6.tinypic.com/80mickg.jpg
Thursday, January 17, 2008
Implementing SSL on Weblogic Web Servers
Monday, January 7, 2008
PeopleSoft Enterprise Portal 9.0
Implementing PeopleSoft Enterprise Portal Solution requires a thorough understanding of the portal concepts, architecture as well as pertinent terminology that relates to PeopleSoft Enterprise Portal.
Portal provides an aggregated content from all systems in the enterprise. The rationale behind portal is to provide a one-stop shop for an enterprise where all relevant functions and content are available on the portal page. Most Enterprise Portal would provides the following feature – Multi-tab HomePage, Search, Content Management, Security, Notification, Personalization, Syndicated News, Web Services, Single Sign-On, Web Access, Web Services and Links.
PeopleSoft Enterprise Portal is a full functional portal platform that provides personal homepage, allows search capabilities, allows content management, provides enterprise navigation and provides template control. PeopleSoft offers the following portal products;
- Customer
- Supplier
- Employee
- Partner
The Enterprise Portal consist of portal features, pagelets and applications. The picture below shows a typical PeopleSoft Enterprise Portal page.
http://i11.tinypic.com/712z4tt.jpg
Understanding PeopleSoft Enterprise Portal Host Database Versus Content Provider Databases
To implement PeopleSoft Enterprise Portal, you need to configure a portal host database. The Enteprise Portal (PA) database is the host database. PeopleSoft application databases that contains the transaction content are called Content Provider databases. An example of your Content Provider database would be your DEMO848 database. Not to be confused with Enterprise Portal (PA) database which host your Enterprise application.
Configuring Enterprise Portal 9.0
- Set-up a separate PS_HOME on the file server (Unix or Windows). Enterprise Portal 9.0 requires PeopleTools to be on 8.48 and higher. The installed PeopleTools used by Enterprise Portal (PA) database and the installed PeopleTools product used by any additional application database cannot be the same. You must have a separate PS_HOME directory for your Enterprise Portal (PA) database.
- Create the Enterprise Portal (PA) database on the O/S of your choice. It is advisable to create a full demo database.
- Set-up Enterprise Portal (PA) database Application Server.
- Set-up Enterprise Portal (PA) database Process Scheduler.
- Set-up Enterprise Portal (PA) database web server. Make sure you configure Authentication token domain when you create the PIA site for Enterprise Portal (PA) database. This is required for Single Sign-On to the Content Provider database. If you successfully configure Enterprise Portal your screen should look similar to this.
http://i14.tinypic.com/8e8yxy9.jpg - Set up the default Portal Registry definition. The Enterprise Portal (PA) database can contain only a single default portal. The Enterprise Portal database is delivered with the default portal of EMPLOYEE. Change this to the portal of your choice. To do this, navigate the following path on the Enterprise Portal (PA) PIA site. PeopleTools > Portal > Portal Definition. A list of available portal name is displayed. Select the portal of your choice and save
- Configure Single Sign-On. This is a very critical step as SSO is required to seamlessly sign-on to different PeopleSoft applications. The following shows how to configure SSO in PeopleSoft Enterprise Portal :
I. Add Content Provider URI path to the portal database
http://i8.tinypic.com/89k0plf.jpg
II. Rename and Configure Password Authentication for the Default Local Node in the PeopleSoft Enterprise Portal
III. Configure Authentication Password in the Enterprise Portal (PA) database
IV. Configure the Enterprise Portal Default Local Node in the Content Provider Database
V. Trust the Enterprise Portal Default Local Node in the Content Provider Database
VI. Configure Authentication password in the Content Provider database (This is for the PA default node)
http://i9.tinypic.com/86trd50.jpg
VII. Configure Enterprise Portal URI Text in the Content Provider
8. Bounce the Enterprise Portal (PA) application server and web server
9. Login to your Enterprise Portal (PA) application and test SSO. To test SSO, click the PeopleSoft link on the left and select the content provider database you configured in Step IV
http://i5.tinypic.com/8er9gu9.jpg
Caveats
You might get the following error when you click on your content provider link on your portal page:
http://i17.tinypic.com/73otojo.jpg
If that is the case, you need to point to your LOCAL_NODE in the Portal Content Reference page. Navigate the following path to point the Portal Content Reference to your LOCAL NODE: Portal > Structure and Content > Portal Administration > Test > Single Sign-On . On the Content Reference section, click the edit link for the content provider database of your choice. Make sure Node Name field is pointing to the LOCAL_NODE of your Enterprise Portal (PA) database :
http://i14.tinypic.com/82tpno7.jpg
Navigate the following path to point the Portal Content Reference to your LOCAL NODE – Portal > Structure and Content > PeopleSoft . Click the edit link for the content provider database of your choice. Make sure you are substituting the LOCAL NODE name on the portal URL field with your LOCAL NODE name :
http://i12.tinypic.com/6ktqk2d.jpg
10. Bounce the Enterprise Portal (PA) application server and clear cache.
11. Log back into the application (PA) and click on the PeopleSoft link on the left. Click on the Content Provider database you configured earlier and you should be able to seamlessly login to the Content Provider database without prompting for password.
Sometime in the future, I'll delve into configuring portal pagelets and customizing your portal page.
Happy New Year!
Wishing you all a very happy and fulfilled 2008. As you've all noticed, I took a long hiatus from blogging last year to attend to some personal needs. This year I'm back and I'll be sharing tips and personal notes from my archives. I will endeavor to keep this page active as much as I can.
Again, Happy New Year!.
