It will also show how to correct the Secure Socket Layer (SSL) certificates so that security scanners such as Foundstone won't complain about the signature algorithm.
Our example server name is
Lines that begin with
SERVER# mean run this command, as root, on the server being set up.
Lines that begin with
LINUX> mean any Linux machine, as any user, will get the job done.
code is usually a computer command.
Text in []s are links.
When SecureID is installed on a 64 bit system, the 64 bit version of the RSA Pluggable Authentication Modules (PAM) is installed. This module is how the log in process talks to SecureID. No surprised there.
The problem is that OpenManage is a 32 bit application, and it wants to log in. This requires the 32 bit version of the PAM module. Fortunately the standard distribution of SecureID also comes with the 32 bit version of PAM. It just has to be installed.
First, dig out the SecureID tar file that was used to install SecureID on the system. Details here are a bit specific to one release because different organizations use different packages.
Unpack the tar file into a temporary directory.
LINUX> tar xvf RSA_100119.tar
Find the 32 bit version of the Linux libraries and extract it. In this example the file being looked for is
pam_securid.so and it resides in
LINUX> cd aagent_60_PAM_96_060308/lnx32 LINUX> tar xvf sd_pam_agent.tar pam/lib/pam_securid.so
Under Linux, 64 bit PAM modules are installed in
/lib64/security. 32 bit PAM modules go into
Care must be taken to not overwrite the 64 bit
pam_securid.so file. Make absolutely sure, before logging out, that logging in to the server works via normal channels after installing this library. If, somehow, the 64 bit library was clobbered, normal log ins will probably stop working unless you disable SecureID.
SERVER# cp -i pam_securid.so /lib/security SERVER# chmod 644 /lib/security/pam_securid.so
Log in to OpenManage. Don't just connect to the server. Start with a fresh web browser so the log in won't be bypassed by a clever web browser. Log all the way in. Poke around to be absolutely sure before logging out of the install terminal.
Web applications that use secure connections need an SSL certificate. Older applications or older versions of Red Hat create certificates that use "md5WithRSAEncryption" as the certificate signature algorithm. This is considered a security problem (Search the web for CVE-2004-2761 if you want more information). The solution is to generate a new certificate using a stronger signing algorithm. The current standard is "sha1WithRSAEncryption".
For self signed certificates it's not really a big deal, but it upsets some security scanners. Foundstone rates this as a "Medium" so it's easier to fix than to ignore.
One of the painful truisms is that graphic interfaces make some things trivial and other things imposable. Fixing the SSL certificate via the web interface falls into the "imposable" category. The interface can generate new certificates, but it won't change the signing algorithm. To do that an "out of band" solution is needed.
The first step is to verify that the application is using a questionable certificate. This is done by connecting to the server and querying the port.
By default the OpenManage port is 1311. Connect to it using the following command:
LINUX> echo | openssl s_client -connect fake.server.com:1311 \ | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \ | openssl x509 -noout -text
Check for the first "Signature Algorithm:" line. If it reads "md5WithRSAEncryption" then Foundstone is unhappy and a new certificate must be generated. If it reads "sha1WithRSAEncryption" then the signature is good and nothing more needs to be done.
The certificate can also be checked using a web browser that allows you to view the certificate. Firefox allows this. Make a connection to the service with a URL like https://fake.server.com:1311. Click on the little lock icon in the lower right hand corner.
The certificate is kept on the server in a file called
keystore.db. The command to access
keystore.db is called
The default place for
keytool is in
keystore.db isn't in the default location, use the
locate command to find it.
To keep things readable, temporarily add
/opt/dell/srvadmin/jre/bin to root's PATH variable.
SERVER# PATH=/opt/dell/srvadmin/jre/bin:"$PATH" SERVER# cd /etc/srvadmin/iws/config
Make a backup and working version of the keystore.
SERVER# cp -p keystore.db keystore_orig.db SERVER# cp -p keystore.db keystore_work.db
A password is required to access the keystore. It's stored as plain text in the file
keystore.ini. The default password is "password". The examples below assume that the default password is used.
Make sure that this is the right keystore. It should have a certificate with the alias "dell".
SERVER# keytool -keystore keystore_work.db -list -alias dell
There should be an entry similar to:
dell, Aug 26, 2010, PrivateKeyEntry,
The current issuer information can be used to minimize the impact of the certificate change.
SERVER# keytool -keystore keystore_work.db -export -alias dell \ -file /tmp/wc.cer SERVER# keytool -printcert -file /tmp/wc.cer SERVER# rm /tmp/wc.cer
There should be a line similar to this: (I've broken it up across multiple lines for readability)
Issuer: CN=fake.server.com, O=Dell Inc, \ OU=SA Enterprise Software Development, \ L=Round Rock, ST=TX, C=US
There will probably be a line which reads:
Signature algorithm name: MD5withRSA
The "correct" line will reads:
Signature algorithm name: SHA1withRSA
The new certificate varies from the default in 2 ways. First it uses "SHA1withRSA" to sign the signature. That will shut up Foundstone. Second it makes the certificate valid for around 10 years (3650 days). Unless a server is an active target for spies, it doesn't need to have its keys updated yearly. Note: It the command below, the text after "-dname" is a single line of text.
SERVER# keytool -keystore keystore_work.db -selfcert -alias dell \ -keypass password -sigalg "SHA1withRSA" -validity 3650 \ -dname 'CN=fake.server.com, O=Dell Inc, OU=SA Enterprise Software Development, L=Round Rock, ST=TX, C=US'
You can verify the new store with the technique used in the Get the Certificate Issuer section. Verify that the "Signature algorithm name" is "SHA1withRSA".
If all looks good, update the
keystore.db file. It has been backed up, right?
SERVER# mv keystore_work.db keystore.db
Restart all the services.
SERVER# /usr/bin/srvadmin-services.sh restart
After about a minute everything should be back up.
Check the certificate via Check Out the Certificate.
Connect to OpenManage via the web browser to see if it's working.
The OpenWsMan project is intended to provide an open-source implementation of the Web Services Management specification (WS-Management). It may not always be installed with OpenManage, but, if it is, the certificate may need upgrading.
On the server run:
SERVER# netstat -tulpn | egrep openwsmand
If nothing is printed then OpenWsMan isn't running. If this is printed:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 24411/openwsmand
then OpenWsMan is running on port 443 with a process id 24411.
Check the certificate using the same technique used in the Get the Certificate Issuer section.
If the signature is "md5WithRSAEncryption" then it needs to be updated.
Grepping for openmange in
/etc/init.d shows the file
/etc/init.d/openwsmand yields a reference to
/etc/openwsman/owsmangencert.sh. The certificate is in
This certificate is created directly, without the intervention of
SERVER# cd /etc/openwsman
Back up the current certificate and the sever key. The server key wont be changed, but better safe than sorry.
SERVER# cp -p servercert.pem servercert_orig.pem SERVER# cp -p serverkey.pem serverkey_orig.pem
SERVER# openssl x509 -noout -text -in servercert_orig.pem
If the first "Signature Algorithm: line reads "md5WithRSAEncryption" then a new certificate is required. If it reads "Sha1WithRSAEncryption" then no changes are needed.
Also note the "Issuer:" line. Broken up on multiple lines, it will look something like:
C=US, ST=New York, L=Buffalo, O=Company, OU=UNIX, CN=fake.server.com/emailAddressemail@example.com
This information can be used to generate a new certificate. Actually, there is no technical need to use the above information. Using it just minimizes the impact of the change. If there are more useful values feel free to use them.
Because the certificate is being generated on the same machine the key resides on, a Certificate Signing Request (CSR) isn't needed. The generation can be done in one step.
Note: Because a self signed certificate was generated for OpenManage earlier, care must be taken so that this new certificate has a different serial number than the OpenManage certificate. If they both have the same serial number, some web browser will kvetch. The -setserial flag solves this problem.
The following command will ask you a series of questions. If you have no better values, then use the ones from the Check the Old Key section.
SERVER# openssl req -set_serial 01 -sha1 -days 3650 \ -new -key serverkey.pem -x509 -nodes -out servercert_new.pem
Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:New York Locality Name (eg, city) [Newbury]:Buffalo Organization Name (eg, company) [My Company Ltd]:Company Organizational Unit Name (eg, section) :UNIX Common Name :fake.server.com Email Address :firstname.lastname@example.org
SERVER# openssl x509 -noout -text -in servercert_new.pem
The Signature Algorithm: should read: "sha1WithRSAEncryption". The "Issuer:" line should look much like it did for the old certificate.
SERVER# mv servercert_new.pem servercert.pem SERVER# /etc/init.d/openwsmand restart
Verify the certificate using the same technique used in the Get the Certificate Issuer section.
Date: 2010-08-29 15:05:08 EDT
HTML generated by org-mode 6.21b in emacs 23