I was putting a Campus Solutions Bundle on a system for a client and as per usual PeopleSoft delivered an emergency ISIR patch to follow up.  However, this time when I went to apply the ISIR patch after the fact Change Assistant was complaining that the pre-requisite bundle was not applied yet.  Now I know my memory is bad, but it was just the other day, I know I put the patch on this environment.

First, I thought cache, so I stopped all the agents and all the environments cleared the cache and reset the PSEM Agents & Hub.  Fired it back up and still the same error.  I even reset the GUID on PSOPTIONS.

I checked the PS_MAINTENANCE_LOG and clearly the update I put on is there, however, it looks a little different on one of the fields for other bundles.  The FIXOPRID for the bundle was PS and not PPLSOFT like the other bundles.  Sure enough I did a

UPDATE PS_MAINTENANCE_LOG SET FIXOPRID = ‘PPLSOFT’ WHERE UPDATE_ID = ‘{CSBundle##}’

Re-ran the check and sure enough all is right in the world again.  All pre-requisites need to have the FIXOPRID be PPLSOFT otherwise things don’t go as planned.

Here is an oldie that loves to surface every once in awhile.  I was fixing some Windows Process Schedulers today so that Crystal would work properly.  I was able to get DEMO working but when I went to one of the test environments I got a connection error, login was denied.  I always love how there are some crazy oddities to 3rd Party programs with PeopleSoft.  Firstly, Crystal is still a 32 bit application even though as of 8.53 PeopleTools all the PeopleSoft connections are 64 bit.  If you are wondering yes SQR is still 32 bit as well. 🙂

However, the login was being denied because there was multiple entries in the PSACCESSPRFL table, and several of them were invalid, and Crystal likes to “randomly”  pick an entry from the table as it does not have a where clause associated with its connection.  So in this case I simply changed all the symbolic ids to use the same accessid and password, however, if you really do need to have multiple accessids, make sure they have the right access.

Weblogic Web Server SSL Certificate:

A client called today and said they needed to change their wildcard SSL certificate that they were using on one of the external web servers. This seemed like a simple enough request, so:

Step 1:

Get Client to send the new SSL Certificate in pfx format.

Step 2:

Using Portecle “a user friendly GUI application for creating, managing and examining keystores, keys, certificates, certificate requests, certificate revocation lists and more” – Load the PFX SSL Certificate

Step 3:

Convert the new keystore to JKS format.

Step 4:

Reset the password to the SSL Certificate and set the Alias name to the Alias already in use.

Step 5:

Export the PEM encoded certificate to a file and set the file extension to .CRT – This allows the SSL Certificate to be easily opened in Windows.

Step 6:

Export the intermediate and root certificates in base x.509 formats.

Step 7:

Import the intermediate and root trusted certificates (the ones just exported in Step 6) back into the keystore.

Step 8:

Take the SSL Certificate in PEM format and append the SSL Certificate Intermediate PEM format and then the SSL Certificate Root Certificate Authority (CA) in PEM format.  This basically creates a full certificate chain in PEM format.

Step 9:

In Portecle update the CA Reply of the Certificate with the Full Certificate Chain in PEM format.  This step is important so no certificate errors are reported with Firefox Browser.

Results:

The new JKS Keystore has 3 SSL Certificates in the keystore, the Full SSL Certificate private/public key combination, and the SSL Certificate Intermediate and SSL Certificate Root.

Install New SSL Certificate Keystore:

Log into the Weblogic Server and rename the existing SSL Certificate Keystore and upload the new SSL Certificate Keystore using the original SSL Certificate Keystore filename.

Restart the server, and………..

BOOOOOOOM!

ERROR:  <Emergency> <Security> <BEA-090034> <Not listening for SSL, java.io.IOException: Cannot convert identity certificate.>

Well, that’s new!  A quick investigation on Google, and some checking turns up that the new certificate was created using SHA256withRSA, while the old one used SHA1withRSA.

As it turns out, Weblogic prior to 10.3.4 cannot use certificates with SHA256withRSA encryption as it uses Certicom SSL implementation.  However, since the web server is version 10.3.6, JSSE SSL needs to be enabled.

Which is under the advanced options of the Weblogic console found under the SSL tab for the Server in question.  Once enabled and the web server restarted, the SSL Certificate & New Keystore worked!

Knowledge Reference:

Check out Wikipedia’s page on SHA-2 Encryption information.

The other day, a trainer was in one of my new demo environments setting up for a demo and told me the time was wrong.  However, if you looked at the server the time was bang on except for the fact that it was using the UTC-0 Timezone, which is common for virtualized cloud server because what timezone you want is really up to you.

I was very surprised that PeopleSoft did NOT seem to acknowledge the servers timezone and adjust accordingly.  So in my case, the demo was in the eastern time zone, so I changed the server timezone to America/Toronto.  To do this, I found was a little less than straight forward:

server1 :>   cd /etc

server1 :>   mv /etc/localtime /etc/localtime.orig

server1 :>   ln -s /usr/share/zoneinfo/America/Toronto localtime

There are hundreds of timezones you can set to but for me that one worked great.  If I need to I can revert back to utc-0 by simply moving the localtime.orig back to localtime filename.  Once the change was made the database booted with the correct time and PeopleSoft worked correctly after that.  I tried to figure out from the support site why UTC-0 was not recognized but found no valid answers anywhere.

Last week while working on a new install of O-SES for a development server, instead of using a dedicated SSL certificate we decided to use a wildcard certificate to reduce headaches.

When trying to build the PTPORTALREGISTRY index it failed with the error showing up in the web server logs:

####<Oct 3, 2014 3:18:25 PM EDT> <Warning> <Security> <OSESDEV> <search_server1> <FlexSecThread-16> <<anonymous>> <> <669085ede0c2399a:-42f78039:148d7454212:-8000-0000000000000031> <1412363905243> <BEA-090504> <Certificate chain received from osesdev.thesmartpanda.com – 111.142.22.208 failed hostname verification check. Certificate contained *.thesmartpanda.com but check expected osesdev.thesmartpanda.com>

Weblogic has a feature that validates the hostname when the web server is acting as a client.  Under the SSL settings for the PIA under the advanced options you can set the “Hostname Verification” to NONE.

After the change, re-ran the initial index builds and everything worked as expected.