Automating SSL Certificate Deployments for HP iLO

Self-Signed Certificates Considered Annoying

You’ve likely seen this warning countless times when accessing self-signed SSL-encrypted web applications, such as the one used for remotely managing HP servers through iLO:

In order to get on with your business, the only real choice is to rotely click the not recommended link.  Using iLO doubles the annoyance because the prompt appears again when subsequently opening a remote console window.

The solution, of course, is to install signed SSL certificates to stop web browsers from complaining.  Given a private Certificate Authority (CA), installing signed certificates is normally an interactive process that involves some clicking and pasting.  Take a look at these articles from Jason Boche and Mike Laverick for additional background.

The one-by-one manual approach is fine for a handful of systems, but setting up a c7000 chassis full of 16 blade servers is an opportunity begging for automation.  In this article I will show you how to become your own CA and write a simple script that automatically deploys a signed SSL certificate to an HP iLO controller.

Overview

From a high level, these are the tasks:

1. Become your own CA with a Linux system and OpenSSL
2. Import that CA certificate into web browsers
3. Download the HP Perl iLO utility
4. Adapt the sample shell script below to work in your environment

Keep in mind that the process described here works best for environments where a known group of individuals needs to administer servers, such as in a lab.  For production systems with many users, certificates from a trusted CA are much more appropriate.

Becoming Your Own CA

Most Linux distributions come with OpenSSL and everything needed to run your own private CA — naturally, I am using SLES for VMware.  Locate the script called CA.pl and optionally increase the CA certificate expiration from 3 years to 10 years, e.g.:

vi /usr/share/ssl/misc/CA.pl

Find the following line and modify accordingly:

$CADAYS="-days 3650";

Next, create a directory to use for the base of your private CA and run the following command there, following the interactive prompts:

/usr/share/ssl/misc/CA.pl -newca

I also chose to remove the passphrase from the resulting private key in order to make the automation script simpler.  To create an unprotected version, use the following command and then rename/swap with the original:

openssl rsa -in ./demoCA/private/cakey.pem -out nopasswd-tmp.pem

Have a look at /etc/ssl/openssl.cnf to change certain default behaviors — optional.

Import CA Certificate to Web Browsers

Next you need to tell your web browser(s) to trust your private CA — you’ll also need to distribute this certificate to other administrators on your team so they can do the same.

The certificate is located by default at ./demoCA/cacert.pem;  take a copy and rename it with a .crt extension to make it easier to import — simply double-clicking in Windows will get the process started for Internet Explorer.  Be sure to import into the Trusted Root Certification Authorities:

Firefox has its own certificate store, which can be reached as seen here — be sure to select the Authorities tab:

Set Up iLO Utilities

Download the HP Lights-Out XML PERL Scripting Sample for Linux in order to get the locfg.pl script.  You may need to install a couple of additional Perl modules to get everything working — see the documentation if you get stuck.  Hint: you can most likely use the package manager for your Linux distribution to add the modules.

Here is a test command to run in order to verify things are working:

locfg.pl -f Cert_Request.xml -u Administrator -p s3kr3t -s ilo-host-name

If an XML response is returned that includes a CERTIFICATE REQUEST element, you are ready to get started with the automation…

Create Automation Scripts

Place locfg.pl and the following 4 files in the same directory that was previously created for the CA:

auto-ilo-cert.sh

#!/bin/bash

AUTH='-u Administrator -p s3kr3t'

if [ $# != 1 ]; then
        echo "Usage: $0 " >&2
        exit 1
fi

ILO=$1
echo "running on $ILO..."

echo "subjectAltName=IP:"`host $ILO | awk '{print $4}'` > $ILO.ext

./locfg.pl -f Cert_Request.xml $AUTH -s $ILO > $ILO-req.pem

openssl ca -policy policy_anything -batch -extfile $ILO.ext -days 3650 -out $ILO.pem -infiles $ILO-req.pem
openssl x509 -in $ILO.pem -outform PEM | cat Import_Cert_A.txt - Import_Cert_B.txt > Import_$ILO.xml

./locfg.pl -f Import_$ILO.xml $AUTH -s $ILO

Import_Cert_A.txt

<RIBCL VERSION="2.0">
  <LOGIN USER_LOGIN="" PASSWORD="">
  <RIB_INFO MODE="write">
    <IMPORT_CERTIFICATE>

Import_Cert_B.txt

</IMPORT_CERTIFICATE>
    <RESET_RIB/>
  </RIB_INFO>
  </LOGIN>
</RIBCL>

Cert_Request.xml

<RIBCL VERSION="2.0">
  <LOGIN USER_LOGIN="" PASSWORD="">
  <RIB_INFO MODE="write">
    <CERTIFICATE_SIGNING_REQUEST/>
  </RIB_INFO>
  </LOGIN>
</RIBCL>

After all of the files are saved, chmod +x the shell script and execute it passing the hostname of an iLO controller as the sole argument.  If everything works, repeat for each server or wrap it up in a loop and deploy certificates en masse.

Manually Signing Requests

It’s easy enough to use your new CA to manually sign certificates from other web services such as Microsoft IIS or the HP Onboard Administrator (OA) controllers.

Simply generate a certificate request and save in a text file, e.g., myweb1-req.txt.  Then run the following openssl command to create a new certificate:

openssl ca -policy policy_anything -days 3650 -out myweb1.pem -infiles myweb1-req.txt

Use the contents of the resulting output file to complete the original request.

Server Name Considerations

Browsers are very particular about server names — if they do not match the certificate exactly, a warning will be thrown.  One key decision to make when using the script above is whether to use short hostnames or FQDNs — I prefer the former.

Another issue specific to HP BladeSystem is that when an iLO console is launched from the Onboard Administrator, the iLO IP address is used and not the hostname.  Fortunately, this overcome by adding the subjectAltName parameter to the certificate.

Note that there is an advanced option in Internet Explorer that may be useful to prevent warnings about certificate names not matching:

Concluding

If you are tired of dismissing the warning messages that accompany self-signed certificates, it might be time to set up your own private CA.  By investing some time up front, it becomes simple to deploy new certificates when adding servers.