PowerEdge: How to import an externally created custom certificate and private key into the iDRAC

Background

Beginning with the iDRAC6, it has been possible to create a certificate leveraging the PKI and import certificates into the iDRAC. It allows for more control over certificate creation process and allows for automation of these processes. Lastly, this process can be leveraged to create and import a wildcard certificate into the iDRAC. From a security stand point, the use of wildcard is not best practice; however, the process used to create any external certificate can also be leveraged for a wildcard certificate.

 

Table of content

1. Certificate creation using OpenSSL
2. Private key creation and certificate signing
3. Upload certificate in iDRAC

In order to import the SSL certificate you need a private key, and a signed certificate for that key.  Certificates can be third party provided or auto-generated.  Here is a rudimentary example of the certificate creation process using OpenSSL in a windows environment: 

 OpenSSL Private key and certificate for use as Certificate Authority

The installation must function as a Certificate Authority.  This allows us to issue or sign a certificate request.  Here are those steps:

1. Creating the CA private key:
   • You must provide a password for the private key.  This is needed later so remember this.

 bin>openssl.exe genrsa -aes256 -out keys/ca.key 2048

1. Creating the CA Certificate leveraging the created key:
   • You are prompted for details about the certificate.  These include the common name and the location data.  The most important field here is the Common Name.  This is going to the identity of the CA, and is reflected in the certificate.  Typically, this needs to match the name by which is accessing the system (DNS hostname for instance).  This field is highlighted in the screenshot below.

bin>openssl.exe req -config openssl.conf -new -x509 -days 3650 -key keys/ca.key -out certs/ca.cer

Now that a private key and certificate are available to use for a Certificate Authority, we can create a private key and CSR for the iDRAC and then sign this request leveraging our Certificate Authority certificate.

 

Creating the private key, Certificate Signing Request, and Certificate for the iDRAC web services

For the iDRAC, we must have a key and a signed certificate to import into the web services.  We can leverage OpenSSL to achieve these goals.

1. First, we must create a private key and a certificate signing request (CSR) that we can then sign leveraging the CA certificate.  The key and CSR can be created in the same step:
   1. You have to fill out the certificate details.  The common name for this certificate should match the name by which we are accessing the iDRAC. Highlighted below
   2. Also of note, you must include a passphrase for the private key that is being created. Highlighted below

bin>openssl.exe req -new -config openssl.conf -newkey rsa:2048  -nodes -keyout idrac.key -out idrac.csr

2. Next, the certificate we created must be signed by the Certificate Authority.

bin>openssl.exe ca -policy policy_anything -config openssl.conf -cert certs/ca.cer -in requests/idrac_web.csr -keyfile keys/ca.key -days 365 -out certs/idrac_web.cer

3. We now have the necessary components to upload to the iDRAC.  The first of these is the private key (idrac_web.key) and the second of these is the signed certificate (idrac_web.cer). 
   
    

Upload certificate in iDRAC

With a private key and certificate pair, we can upload the key and certificate to the iDRAC. *Note for the following steps I copied the private key and the certificate to the root of the C drive for ease of access and to decrease the length of the commands.

1. First, we must upload the certificate:
   • I leveraged remote racadm command with the interactive option

racadm -r 10.14.177.107 -i sslkeyupload -t 1 -f C:\idrac_web.key

1. With the key uploaded, we must upload the certificate.  The command for this is:

racadm -r 10.14.177.107 -i sslcertupload -t 1 -f c:\idrac_web.cer

1. After the web interface has come back, we must verify our certificate.  This can be done by accessing the web interface in any browser, and then inspecting the certificate.  You should see that the certificate reflects the configured common name and is issued by the common name configured in your CA: