LOTUSCONNECTIONS.org

In WebSphere you have a SSL certification expiration checker. This
mechanism monitors the expiration dates of all the SSL certificates
that are configured in WebSphere.

You can control how many days before the cert. expires WebSphere will
send a notification mail and in what frequency the check has to be performed.

Notification per mail need to be configured with a SMTP server an a recipient
address.

You also have the options “Automatically replace expiring self-signed certificates“
and “Delete expiring certificates and signers after replacement“.

But in a Connections setup these two options will not take away any manual
work. If you got a Connections config with a IHS webserver in front you will always
have to export the new SSL key and import it into the plugin-cfg.kdb file
of the WAS-plugin on the IHS webserver. If you don’t do this the connection
between WebSphere and the IHS webserver will not work any longer.
Clients will be faced with 500 error pages when they want to visit Connections.

All things written above work perfectly, the only thing that doesn’t function the
way you want it is the sending of the notification mails.
The mails will be sent either the certification expires or not. With a notification
treshhold of 30 days and a Connections setup will multiple JVM servers
you will receive 11 mails of certifcates that aren’t about to expire every
30 days .

Described behavior has been noted and is fixed in WAS version 6.1.0.27.

Check the technote.

If you don’t want to do a install a complete new fixpack we also got
our hands on the ifix. Which will not have that much impact on your
WAS install as a complete new Fixpack.

We now just renew the certs. of WebSphere to somewhere in the end
of 2020 and disable the SSL certificate check. This to get rid of installing
a fixpack or ifix for every LC installation and keeping this up to date.

The default expiration date for WebSphere it’s own SSL certificate
is one year, but my experience is that this can vary with every fixpack
level.

At our company we use SLES as the favored Linux distribution. 

Sudo and su are used to make things on the servers work
a little bit more secure.

We had problems on some dated versions of SuSe with running
the su command in combination with ulimit settings.

Limits were set in the file /etc/security/limits.conf for a particular
user but after a su switch to that user the limits set weren’t
honored.

Problem was that the pam_limit module wasn’t loaded in the /etc/pam.d/su
configuration file. Just added the rule

session required        pam_limits.so

to the file after that limits were handled correctly when using the su command.

In later versions of SLES the whole PAM configuration is set-up
a little bit different. There are common config files which are
included by the different sub parts.

/etc/pam.d/su
session include common-session

/etc/pam.d/common-session
session required pam_limits.so