Here is another great guest post from: Jason Boche, MCSE NT4/2000/2003, MCSA 2000/2003, MCP, VCPx2, CCA, A+

If you have used Compaq/HP brand server hardware, you are most likely familiar with RILOE boards (Remote Insight Lights Out Edition) and ILO boards (Integrated Lights Out). These are hardware devices that provide remote access to Compaq/HP server hardware. A key benefit is their "out of band" management attribute, meaning they operate independent of the server's native host operating system, network, and CPU. They've got their own CPU, memory, and a built in web server which listens on ports 80 and 443 and serves as the configuration and management tool. Another benefit is the encrypted traffic that passes along the wire between RILOE/ILO and the client web browser which is accessing it. By default, this traffic is passed on TCP port 443. If you've used the RILOE/ILO before, you are probably used to seeing the following all too familiar screen:

The underlying reason for this is that your client knows nothing about the certificate authority from which the certificate for the RILOE/ILO was generated, other than it is not trusted. This is no cause for alarm as long as you trust the Hewlett Packard company from Houston, TX, however, failure to address this will cost you an extra mouse click each and every time you access this or any other RILOE/ILO on your network. Considerably more harmful is the numbing effect this screen will cause for each administrator who is presented with it. The danger here is that the administrator develops an acquired immunity to the warning which the administrator has learned he or she can immediately bypass by clicking the middle link "Continue to this website (not recommended)". At a later time when a similar warning is presented for legitimate reasons, the administrator's click happy impulse may kick in, inviting internet treachery to the environment.

RILOE and ILO boards support certificate requests which allows us to import trusted certificates into the RILOE/ILO's built in web server. If you own and/or operate a Microsoft Certificate Authority (CA), this is one solution that you can follow. An Enterprise CA is the most ideal since all clients who are members of the domain the CA resides in, will automatically trust certificates issued by that CA.

In the following demonstration, I will show you step by step how to use the RILOE/ILO to request a certificate from an internal Microsoft Enterprise CA, retrieve the certificate, and then import the certificate into the RILOE/ILO. I will use a CA from my home lab for this demonstration. The domain is boche.mcse and the Microsoft Enterprise CA is named boche.mcseca. The screens are from a RILOE but I assure you the screens from an ILO are nearly identical.

The first step to this process would be to make sure you have the fundamental components in place to make it work.

Enterprise CA? Check.

My Enterprise CA is among those in the Trusted Root Certification Authorities list? Check.

http://<servername>/certsrv/ integrated web page? Check.

Of course we need a RILOE or ILO. Check. (Note that since I do not have a trusted certificate installed, or if the host name in the issued certificate is different than the encrypted URL being accessed, we see a Certificate Error in Internet Explorer 7 along with the red background. This is meant to raise red flags.

With that, let's dig in. Don't worry, it's not difficult. One thing I'd like to point out with certificates is that you should try to use fully qualified domain names (FQDN) as much as possible. It's not absolutely required in all cases (think local intranets) but it should be followed as a best practice because anything done over the internet will need to use FQDNs.

Step 1: Access the Certificate Administration menu in the RILOE/ILO.

Step 2: Use the RILOE/ILO to generate a certificate request for it's built in web server. Note this will be a base64 encoded request.

Step 3: The base64 encoded certificate request is generated. Select all text in the window using CTRL + A, then copy using CTRL + C. The base64 encoded certificate request is now on your clipboard. It is important to leave this web browser window as is. Do not close it or surf to a different web page until this process is complete. If you do, you'll have to start over at Step 2.

Step 4: Using a new browser window, surf to the certsrv URL of your Enterprise CA. /certsrv/">http://<yourservername>/certsrv/ Choose Request a certificate.

Step 5: Choose advanced certificate request.

Step 6: Choose Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

Step 7: In the Saved Request box, paste the contents of your clipboard which should be the base64 encoded certificate request which the RILOE/ILO made. For the Certificate Template, choose Web Server. Then choose Submit.

Step 8: Chose Base 64 encoded and click Download certificate.

Step 9: Choose Save

Saving to your desktop is fine:

Step 10: Go back to your RILOE/ILO certificate request window and click the Next Step button.

Step 11: You are presented with an empty box in which you need to paste the newly issued certificate:

Step 12: Find the saved certificate on your desktop and open it with notepad.exe.

Step 13: What you're looking at is the base64 encoded certificate. Once again, select all by using CTRL +A and copy by using CTRL + C

Step 14: Paste the contents of your clipboard (which should be the base64 encoded certificate) into the X.509 Certificate Data window, then click the Import Certificate button.

Step 15: If all went as planned, you should see a successful screen with the request to reboot the RILOE/ILO. Go ahead with the reboot. This will take about 15-30 seconds.

Note that if a step was missed or goofed along the way, you'll need to start over from step 2. Note that you will also want to "REVOKE" the certificate you requested in your failed process. This can easily be done using the CA console.

Step 16: While RILOE/ILO is rebooting, let's take a look at the Certificate Authority console on the Enterprise CA and identify the newly issued certificate along with some of its attributes:

Step 16: With the RILOE/ILO rebooted, we should now be able to access the device using a trusted certificate with no warnings or alarms. Notice that when I access the website, I have a padlock now instead of a warning with red background. This padlock ensures the SSL encryption along with a certificate which was issued by a trusted Certificate Authority (CA). Notice the additional information that is displayed when clicking on the padlock.

Going back to the Certificate Administration applet in the RILOE/ILO, I see some details on the imported certificate.

16 steps sounds like a lot but try to remember these are baby steps. With the proper infrastructure in place and basic familiarity, you could really summarize this whole process down to just four steps.

1. Generate a certificate request.

2. Send the certificate request to a CA and receive a certificate.

3. Import the certificate into Remote Insight Lights-Out Edition II.

4. Restart Remote Insight Lights-Out Edition II.