Wildcard SSL + PeopleSoft

Out of the box you can do just about anything with WebLogic, however, when you get into some of the specifics and try to tie it into an application like PeopleSoft you can run into some interesting quirks.  I personally really like wildcard SSL certificates because it cuts down on a huge administrative headache that can come from trying to manage certificates for every “name”  that needs to be managed.  In PeopleSoft you can have dozens of servers and it can get to be an administrative nightmare.

WebLogic allows you to store and reference the wildcard certificate in you keystore, however, Wildcard Host Name Verification will fail with default settings.  If you do a quick google search you will turn up several posts that explain to simply “ignore” wildcard host name verification.  I am not a fan of just “ignoring” things.  So you could simply add the following to the start command of Weblogic:

-Dweblogic.security.SSL.ignoreHostnameVerification=true

However, I found what I consider a better option which is to set the validation to a custom wildcard host name verification with a delivered public class for WebLogic Security: SSLWLSHostnameVerifier, which can be called for hostname verification and will apply wildcard host name verification checks. This wildcard host name verification is instantiated by the WebLogic hostname verifier wrapper that checks for proxies, expectedName, etc. It obtains this hostname verifier class name from the SSLMBean or the hostname verifier property.

In the WebLogic Console:

you can change the advanced SSL properties:

Hostname Verification:

Custom HostName Verification

Custom Hostname Verifier:

weblogic.security.utils.SSLWLSWildcardHostnameVerifier

This will do a check of the peer certificate of the SSL session’s peer certificate SubjectDN CommonName attribute supports wildcarding, the CommonName attribute must meet the following:

• the CN must have at least two dot (‘.’) characters
• the CN must start with “*.”
• the CN can have only one “*” character

As of PeopleTools 8.50 PeopleSoft no longer requires the NSS cert7.db or Oracle Wallet Manager and all the crazy setup in order to get the LDAPS configuration to work. As of 8.50 PeopleSoft uses the Java Naming and Directory Interface (JNDI) API which allows Java software clients to discover and look up data and objects. JNDI being a JAVA API means that it is independent of the underlying implementation.

There is no need for additional installations and the certificates no longer need to be stored on the application server domain folders, all the certificates are stored in the database.

In order to setup LDAPS, you will need the Root CA certificate for the LDAPS Server, in my case I am using Active Directory so I went on my domain controller and went into the certificate store and exported the CA certificate for the server. Next you need to import that certificate into the digital certificates within PeopleSoft.

Home > PeopleTools > Security > Security Objects > Digital Certificates

Next, you need to add a Root CA, and give it an Alias Description – click refresh – you you will see hyperlink to import the certificate. Next you will want to copy the “pem” format of the CA certificate into the window. The easiest way to get this format is to export the file in Base x.509 format while viewing the certificate.

Bounce the application server and you should be able to Test Connections to the LDAPS server:

In the old days of PeopleSoft you needed to create a cert7.db database file in order to do things like LDAPS. However, to create an cert7.db file requires very old software because this format is very uncommon today. I have found you can create a cert7.db file using Netscape v4.7.3 or earlier according to various websites. However, I am very suspect of downloading old versions of software. There is an old toolset NSS (Network Security Services) & NSPR (Netscape Portable Runtime) available from Netscape (Mozilla) which does a nice job in creating the cert7.db.

To download I found you want to get version: NSS v3.4.2 and NSPR v4.1.2 use the Mozilla FTP site:
https://ftp.mozilla.org/pub/security/nss/releases/
https://ftp.mozilla.org/pub/nspr/releases/

I unzipped the files to separate directories, and then used a command prompt to setup the PATH to include both directories library’s:

SET PATH=%PATH%;%NSS_PATH%/lib;%PATH%;%NSPR_PATH%/lib

From the \bin directory, we need to run the certutil to create a new NSS Certificate Database:

certutil -N -d c:\temp\certdbfolder

To Add The Root CA Certificate:

certutil -A -n MyCA -d c:\temp\certdbfolder -i CA.cert -t C,C,C

To Add The Server Certificate:

certutil -A -n MyServer -d c:\temp\certdbfolder -i server.cert -t P

In order to use the cert7.db in the PeopleSoft Application Server, depending on your Tools & Application level you will want to put the files cert7.db & key3.db & secmod.db in the Application Server Domain root directory or in a folder “cert” in the root directory.

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.

The other day I was configuring a new production system for a client and I ran into something I have never seen before. I was trying to test the SSL certificates on the new servers and since the old servers are still running in production I can’t change the DNS entries so I simply fired up UltraEdit and modified my hosts file to have the new server IP point to the new server SSL host name. This always works for me, except this time. I checked the logs and I am seeing all sorts of odd SSL revoked errors in the logs and I am seeing the OLD IP address instead of the new IP address.

I am completely puzzled, all I can see is that I am not picking up the new IP address from the hosts file. After running this by one of the server administrators he tells me that he has seen the problem before, and that I need to disable the DNS Client Service.

DNS Client Service: The DNS Client service is the client component that resolves and caches Domain Name System (DNS) domain names. When the DNS Client service receives a request to resolve a DNS name that it does not contain in its cache, it queries an assigned DNS server for an IP address for the name. If the DNS Client service receives the requested address, it stores the name and address in its cache to resolve future requests without having to query the DNS server. All computers that use DNS to resolve domain names (including DNS servers and domain controllers) use the DNS Client service for this purpose.

Sure enough once disabled, the host file is read and we are able to test the SSL certificate without an issue. I have done some reading on this and I am not completely sure that disabling the service is necessary, however, it did work in this case. From what I read it maybe a problem with the registry or with security on the hosts file. Some people were able to resolve the issue by simply deleting the hosts file and creating a new one which changed the security permissions on the hosts file, others have reported that there is a policy item and the registry is point to an incorrect policy.

Irregardless, for my testing needs, stopping the service and updating the hosts file then validating that the SSL certificates were in place was sufficient.