PeopleSoft Database SSL and REN server SSL setup

Step 1:

Request for Root and chain certificate from CA. He provided the Root/Chain CA

Step 2:

Paste and merge the chain certificate and then root certificate without space as below:

-----BEGIN CERTIFICATE-----    ß---------Chain Certificate

DHzvjJP9QoyDfz8uhZ2VrLWSJLyi6Y+t6xcaeoLP2ZFuQ==

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE----- ß--------- Root Certificate

CI3zJpDC5fcgJCNs2ebb0gIFVbPv/ErfF6adulZkMV8gzURZVE=

-----END CERTIFICATE-----

========================================================================

STEP 3: Import the Entrust chain and root certificate to database

Import the certificate as below to peoplesoft.Navigate to PeopleTools->Security->Security Objects->Digital Certificates

Fill in the below information and click the +add root .Paste the above created in step 2 chain and root certificate by clicking Add root and click ok

Root CA

Entrust Root and Intermed Cer

Entrust Root and Intermed Cer

10/12/19  1:13:54PM

========================================================================

STEP #4. Generate the database Server certificate

Create a certificate request (CSR) from the PeopleSoft database as follows:
    a. Navigate to PeopleTools->Security->Security Objects->Digital Certificates
    b. Click '+' to add a new entry
        i.   Choose type = 'Cert'
        ii.  Enter any Alias name (eg 'REN SSL')
        iii. Click 'Magnifying Glass' next to Issuer Alias and choose the 'Entrust Root and Intermediate Cer' entry you created in step 2 above.
       iv.  Click the 'Request' hyperlink
            - For common name, enter the name of the box that the REN server is on
              eg:xxx.domain.com (Application server)
            - Enter other 'Subject' information (eg Org Unit, State, etc) as appropriate for your company
            - Keep the default values in the 'Key Pair Information' section
            - Leave the 'Additional Certificate Attributes' blank
            - Click 'OK'

. You are now presented with the certificate request.
         i. Copy everything from 'BEGIN NEW CERTIFICATE REQUEST' to 'END NEW CERTIFICATE REQUEST' to clipboard. Then click 'ok'
            Example:
            -----BEGIN NEW CERTIFICATE REQUEST-----
           MIIBlzCCAQACAQAwVzEJMAcGA1UEBhMAMQkwBwYDVQQIEwAxCTA
           etc etc
           -----END NEW CERTIFICATE REQUEST-----
         ii. Send the above information to your certificate authority (CA) and request a certificate.

STEP 5: Import the SSL certificate (Make sure you got certificate as VIP address name)

STEP #4. After you get the signed certificate from the CA, import it into the PeopleSoft database:
    a. Navigate to PeopleTools->Security->Security Objects->Digital Certificates
        i.  Click the 'import' link next to your certificate.
        ii. Paste in the certificate that you received (Server certificate only).
           Example:
           -----BEGIN CERTIFICATE-----
           MIIEJjCCA4+gAwIBAgIQMFbEDgfLmZ <-- Contents of Certificate
           etc etc
          -----END CERTIFICATE-----
        iii. Click OK

Validate the certificate is correct date and time by clicking Details>Configure REN – clear appserver/Webserver cache and reboot

Cert

RENSSLCertificate

Entrust Root and Intermed Cer

31/12/14  3:59:06PM

Detail

How to identify session stickiness problem on load balancer in PeopleSoft environment?

Simple example of load balancer with session stickiness problem

Suppose you have load balancer in front of two WebLogic webservers. In this simple example, we'll call them webserver A and webserver B. When end users logs into PeopleSoft though the load balancer, the end user connects to one webserver.  Suppose the load balancer routes an end user to webserver A. This end user should remain with webserver A during the entire session. While the end user is working in PeopleSoft, if this end user inadvertently connects to webserver B, this means the load balancer is not maintaining session stickiness. End users may experience intermittent problems such as getting kicked back to search page, gettting kicked out of PeopleSoft, premature timeout, seeing "Page is no longer available", images disappearing, 403 errors, appserver showing that certain UserID are logging in PeopleSoft multiple times (looping) and other strange intermittent problems in PeopleSoft.

To determine if session stickiness may be a problem

1. Test without load balancer

If the problem does not appear without the load balancer, the reported problem is likely caused by the load balancer.

2. Test with one webserver running behind load balancer. 

This is a good test, but results may be unreliable since intermittent problem may still appear with just one webserver because various load balancer configuration options may still point at the load balancer

3. Collect browser headers while replicating problem

Please ask some end users to collect browser headers when they log into PeopleSoft until the intermittent problem appears.  Please download free tools such as: iehttpheaders, LIVE HTTP HEADERS, Fiddler, and etc.  You can find these tools with a simple web search.  Once you have header logs, please look at all the POST/GET requests and cookie values before problem appears, exact time problem appears, and after problem appears. Pay close attention to the weblogic webserver cookie called *PORTAL-PSJESSIONID. This webserver cookie value should remain constant (a long encrypted string value) during the end user's entire PeopleSoft session. If you see that the PORTAL-PSJESSIONID webserver cookie value is randomly changing, your load balancer is not maintaining session stickiness.

4.  Turn on WebLogic extended access logging in both webservers behind the load balancer

For instructions on turning on extended access logging, please see Document 644602.1.  This is the most time consuming option and may impact performance in production, but it may provide the most valuable information.   

The extended logging collects all cookies in the same domain that are forwarded from browser to webserver for all end users logging into PeopleSoft.  These include PeopleSoft cookies, WebLogic cookies, 3rd party cookies, and any custom cookies.
Example 1: Session stickiness problems can cause the following behavior:

• End user is randomly kicked out of PeopleSoft in load balanced environment.

• End user kicked back to search page in load balanced environment.

• Premature timeout in load balanced environment.

• Random "Page is no longer available" in load balanced environment

• 403 errors

Here are some troubleshooting tips for the above behavior:
a) Turn on extended access logs in both webservers 
b) Ask end users to attempt to replicate problem.  When problem appears, ask for PeopleSoft UserID and exact time.
c) In webserver A, in extended access logs, search for that UserID. You'll see a PeopleSoft cookie called SignOnDefault that will match that UserID.  For that UserID, please look at all the POST/GET requests and cookie values before problem appears, exact time problem appears, and after problem appears. Pay close attention to the weblogic webserver cookie called *PORTAL-PSJESSIONID. This webserver cookie value should remain constant (a long encrypted string value) during the end user's entire PeopleSoft session. If you see that the PORTAL-PSJESSIONID webserver cookie value is randomly changing, your load balancer is not maintaining session stickiness.
d) In webserver B, in extended access logs, do the same as step c.

Remember, if end user logs into PeopleSoft and connects to webserver A (you should see this UserID in access log for WebServer A) and you start to see entries in webserver B access logs for this UserID, that's a clear sign that load balancer is not maintaining session stickiness.  There is also also a possibility that end user stays on webserver A, but PORTAL-PSJESSIONID is randomly changing.  This also indicates a session stickiness problem.

The extended access logs from the webserver are evidence that the load balancer is not maintaining session stickiness.  Customers should follow up with their load balancer vendor to properly setup session stickiness on the load balancer. 
Example 2: Session stickiness problems can cause the following behavior:

In PeopleSoft load balanced environment, UserID is unknowingly logging in PeopleSoft multiple times (looping) and using up all webserver and appserver resources.

a) Turn on extended access logs in both webservers
b) Make sure appserver psappsrv.cfg has LogFence=3 or higher. Save and bounce appserver
c) In appserver psadmin, select 3 "Domain status menu". Select 2 "Client status". If you see the same UserID appears multiple times, it could be indication of random looping behavior where UserID is unknowningly logging into PeopleSoft hundreds of times. Check appserver log file and search for that UserID to see if this UserID is authenticating multiple times in a short time period. Find the timestamp when this UserID first logged into PeopleSoft in appserver log file

d) In webserver A, in extended access logs, search for that UserID. You'll see a PeopleSoft cookie called SignOnDefault that will match that UserID. For that UserID, please look at all the POST/GET requests and cookie values before problem appears, exact time problem appears, and after problem appears. Pay close attention to the weblogic webserver cookie called *PORTAL-PSJESSIONID. This webserver cookie value should remain constant (a long encrypted string value) during the end user's entire PeopleSoft session. If you see that the PORTAL-PSJESSIONID webserver cookie value is randomly changing, your load balancer is not maintaining session stickiness.

e) In webserver B, in extended access logs, do the same as step d.

Remember, if end user logs into PeopleSoft and connects to webserver A (you should see this UserID in access log for WebServer A) and you start to see entries in webserver B access logs for this UserID, that's a clear sign that load balancer is not maintaining session stickiness. There is also also a possibility that end user stays on webserver A, but PORTAL-PSJESSIONID is randomly changing. This also indicates a session stickiness problem.

The extended access logs from the webserver are evidence that the load balancer is not maintaining session stickiness. Customers should follow up with their load balancer vendor to properly setup session stickiness on the load balancer. 

Example 3: Other random problems that only appear in load balanced environment

This last section just provides some general tips to troubleshoot issues in a load balanced environment. 

a) Turn on extended access logs in both webservers
b) Make sure appserver psappsrv.cfg has LogFence=3 or higher. Save and bounce appserver
c) Ask end user to report when problem appears. Get UserID and time if possible.
d) Review extended access log, appserver log, and all webserver log file for that time period when problem appears.  You may need to cross reference the different log files so see if a certain error or action may have caused the reported problem:

Since extended access logs contain all POST/GET requests and all cookies, it may give a clue what the end user was doing when the problem first appeared. 

• Are there certain POST/GET requests that seems to trigger the problem?
• Do you see multiple PeopleSoft webserver cookies *PORTAL-PSJESSIONID? Perhaps end users was visiting other PeopleSoft sites or certain navigation may have caused problem What values do PS_LOGINLIST and ExpirePage contain?
• Do you see other custom or 3rd party cookies such as load balancer cookies, siteminder cookies, and etc that could be causing problems in load balanced environments? Are these custom cookies suppose to maintain constant or change values?

PeopleSoft Load Balancer Implementation (F5)

STEPS:

--------

1)Configured two Weblogic domains servers with SSL(Refer to Weblogic HTTPS implementation in my old blog)

2)Make two weblogic domains as https:\\servername:80 to get the PS login page

This can be done by creating a soft link to redirect Weblogic admin console page from weblogic to signin.html page.So, when the servername with port is called it gives the PS login page instead of console page

3)Now the F5 device has to be configured with pool with load balanced server name and listening port Eg.,https:\\servername1:80 and https:\\servername2:80.

4)We have to NFS mount a common share such as /reports between Web Domain hosting servername1 and servername2.Configure two web servers with same report repository path as /reports - This is needed because when User hits F5 he will be redirected to any one of the servername 1 or servername2.Lets say he connected to servername1 from F5 and runs report it gets posted to the /reports NFS mount and it available and readable from both servername1 and servername2.Now after some time he login and if he landed on server2 he will still see the report from report repository as /report is a NFS from available from both load balanced servers through F5.

5)Set the Report Node as ABC.xinc.com with port 80 and mode as HTTPS>make sure the F5 load balancer time out value more than the PS timeout otherwise you will see session bounce between different web server.

6)If you are using REN and need SLL configure refer the old blog with REN SSL implementation.Baically We need to Import SSL in to Database to make the REN SSL work.

7)Now yo have two option of choosing session stickiness on the F5 for the connection established session.

    a)Server Ip - Session will lose connection when one of the weblogic is down and we have to relogin and reconnect to connect to second active webserver throuch F5.But the instance will be up and running for new session, it is only issue with connected session.

     b)Cookies enable  - PS Authenticated cookie will be caught on the browser and it will reconnect to active web domain without re - connection .To do this follow below

*********************************************************************************

HOW TO SET PEOPLESOFT COOKIES ENABLED FOR F5 LOAD BALANCE WITH COOKIES ENABLED  STICKY SESSION

---> For customers that use a load balancer, Oracle recommends using a cookie (session) based load balancer and sticky bits enabled.  Please consider using cookie insertion and ensure that load balancer's cookie is configured to be in the same domain as PeopleSoft's authentication domain. Contact your load balancer vendor on how to use the load balancer's cookie insertion.  IP based load balancing is not recommended and IP based load balancing is known to cause session stickiness problems.  Here is one example where IP based load balancing will cause problems: Note 949387.1

DNS Round Robin is not recommended and customer should use cookie based load balancing.

For more information on cookie based load balancing and sticky bits, please follow up with your load balancer vendor.

Vendor URL's for Setting up their Load Balancers with the PeopleSoft Application:

Deploying F5 With PeopleSoft Enterprise Applications

Note: The F5 document referenced recommends "content compression" enabled on the F5, however this can prevent output docs from being opened from the Process Monitor or Report Manager. Disabling F5's "content compression" can resolve the issue of not being able to view reports.

 Cisco Application Networking for PeopleSoft Enterprise Deployment Guide

Questions on the above documents need to be directed to the third party vendor that created these instructions.

---> Ensure all your webservers have the same cookie name in each weblogic.xml file.  This file can be found in the following directory:

/webserv//applications/peoplesoft/PORTAL/WEB-INF/weblogic.xml

In this example, there's two webservers behind the load balancer. Therefore, verify that your cookie names are the same:

weblogic.xml (webserver 1):

CookieName

pststweb-7011-PORTAL-PSJSESSIONID  <--- this name have to be same on both web server

weblogic.xml (webserver 2):

CookieName

pststweb-7011-PORTAL-PSJSESSIONID   <--- this name have to be same on both web server

Save both weblogic.xml files.

Note:  If you're running Enterprise Portal and have content providers, please ensure that all Enterprise Portal webserver cookie name are all exactly the same. The content provider's webserver cookie names should have their own set of cookie names. Therefore, both Portal and content should not have the exact same cookie name. Suppose Enterprise Portal had 4 webservers and HR had 4 webservers. All 4 Enterprise Portal cookie names could be eportal-7011-PORTAL-PSJSESSIONID, but all 4 HR cookie names could be hrms-7011-PORTAL-PSJSESSIONID.  In addition, node URI should point to the load balancer URL, not individual webservers directly.

---> In weblogic.xml, ensure CookieDomain is set in all weblogic.xml. This value is automatically set when entering the authentication domain during the PIA install. If the authentication domain isn't set during PIA install, please reinstall PIA and set authentication domain.  Please see Note 885452.1 for more information on setting/changing cookiedomain.

---> In PIA, navigate to "PeopleTools -> Web Profile -> Web Profile Configurations". Search for your Web Profile. Click on

Virtual Address and populate your default addressing. For example, suppose your end users access your load balancer with the following URL:@ http://mycompany.com/ps/signon.html You would need to set the following:

Default addressing Protocol: HTTP

Default addressing Name: mycompany.com

Default addressing Port: 80

* The above is an example. You'll need to populate with your load balancer info.

It is required that the load balancer and PeopleSoft WebLogic web servers are in the same domain.

---> Please ensure PIA "Inactivity Logout" in seconds matches HTTP timeout in minutes.

a) In PIA, navigate to "PeopleTools -> Web Profile -> Web Profile Configurations". Search for webprofile. Click on "Security" tab. PIA timeout is "Inactivity Logout" in seconds. Suppose "Inactivity Logout" = 1200 seconds.

b) In WebLogic, open web.xml file.  This file can be found in the following directory:

/webserv//applications/peoplesoft/PORTAL/WEB-INF/web.xml

WebLogic HTTP timeout appears in minutes:

20

In this example, ensure WebLogic HTTP timeout is 20 minutes to match "Inactivity Logout" (1200 seconds).

The Load Balancer's timeout should be higher than the PIA "Inactivity Logout" timeout and webserver HTTP timeout. Please consult with load balancer vendor to find out where to set load balancer timeout.

---> After updating weblogic.xml, web.xml and webprofile, you must bounce your webservers. 

For Radware load balancers the setting "Sessions Mode" has several options. Set to "Regular" which tells the load balancer to keep users sessions on the web server that they logged on to initially to maintain session persistence.

 If you have completed all these steps and still experience intermittent problems, it's likely that your load balancer is not maintaining session stickiness.  Please review the document below  for additional troubleshooting.

E-PIA: How To Identify Session Stickiness Problem On Load Balancer? (Doc ID 1307344.1)

*********************************************************************************