Weird DRAC behaviour after applying self signed SSL

Hi Alek,

Did you find a solution?

I'm having the exact same problem. I've been searching high and low without finding an answer, and it's quite annoying.

From the idrac users guide"

CAUTION: Only X509, Base 64 encoded certificates are

accepted by the DRAC 5. DER encoded certificates are not

accepted. Upload a new certificate to replace the default

certificate you received with your DRAC 5.

Or this may help…

lists.us.dell.com/.../035852.html

Thanks for the suggestion, but I don't think that's the problem.

If the generated SSL certificate were DER formatted, I doubt the DRAC would accept it at all, and write an error message, right?

In Alek and my case the certificate is accepted and the DRAC reboots, but the HTTPS server never runs. After the DRAC reboots, you can ping it, ssh to it, racamd it, but there is nothing listening on port 443.

wow ok, so this issue wasn't just me......

but i never solved it, after 6 hours and no forum replies, i gave up

I think the issue still lies in the RAC its not the size or type of SSL its that no private key is loaded to the rac to decrypt the ssl uploaded. i tried a whole bunch when i first had this issues, self signed, but with different bit SSLs and various times, none took......

the RAC may not throw an error while uploading, it might only sanity check it upon load. easy way to tell would be to change a few letters in the SSL and upload it, see if it objects to it, if it does, sanity check is done on upload, if not, its done on web server restart and would explain everything

sorry about spelling errors, im on my phone. also sorry if that link covered any of this

i might have a go when i get home

Scrap some of that....just worked 18 hrs not awake .....

If you use the DRAC to make the CSR it would have the key, but it still doesnt look like its decrypting the ssl. I read that link and its a possibility the ssl needs an extra command to make compatibe, but the command used in that link looks pretty standard......i need to have a play around with open ssl i think

Here's what I've been trying to do, and it doesn't work... But as far as I can work out, I've been doing it the right way, but something keeps going wrong.

1. Update BIOS (2.7.0) and DRAC firmware (1.60) to newest versions.

2.1. root@MyServer:~# /opt/dell/srvadmin/rac5/bin/racadm racresetcfg

2.2. wait for the DRAC to restart, then configure the IP address with 'setniccfg' and restart with 'racreset'

2.3. wait a minute for it to restart and we now have a clean DRAC to start playing with.

3.1 Download the default DRAC certificate, to have something to compare with my own selfsigned certificate.

3.2 # racadm sslcertdownload -f drac.crt -t 1

3.3 # openssl x509 -in drac.crt -noout -text

4.1 Generate a certificate request on the DRAC Web UI.

4.2 Download certificate request with 'racadm sslcsrgen -g -f new_drac.csr'

4.3 Use openssl to generate a key and certificate

4.4 # openssl genrsa -aes128 -out new_drac.key 1024

4.5 # openssl x509 -req -days 365 -in new_drac.csr -signkey new_drac.key -out new_drac.crt -sha1

4.6 We now have a nice new certificate and we can use openssl to compare it wih the old default certificate.

4.7 # openssl x509 -in new_drac.crt -noout -text

4.8 It should look very much like the one in 3.3 just with different values.

5.1 Try uploading the new certificate to the DRAC

5.2 # racadm sslcertupload -f new_drac.crt -t 1

5.3 should result in "Certificate successfully uploaded to the RAC. The RAC will now reset to enable the new certificate and may be offline temporarily."

5.4 BOOM, no more access to the DRAC via HTTPS. You can still ping it, ssh to it, racadm access it, but nothing is listening on port 443.

Ideas are welcome

Has anyone figured this out? I ended up in the same situation today after uploading a new certificate. Unfortunately for me, one difference is that no matter what I try, I can't get port 443 up again.

Hakan,

         After upload iDRAC certificate if you have issue with launching DRAC5 you can run "racadm sslresetcfg" and "racadm racreset" command from FW or Local Racadm to load default certificate.

        To upload a Custom Certificate to iDRAC we need to first create a CSR from iDRAC. Then get this CSR signed by any CA. You will be able to upload this signed certificate back to iDRAC either using Racadm(Local or Remote) or GUI iunterface.

Refer the below links for more details

Uploading SSL Certificate using GUI

Creating a CSR using Racadm

Uploading a certificate using Racadm

<ADMIN NOTE: Broken link has been removed from this post by Dell>

Thanks-

Shine

Shine,

Thanks for the reply. As far as I can tell, I did follow the correct procedure for uploading a custom certificate. Just like Alek and Jesper, I created a CSR from the DRAC, signed it using my own CA and uploaded the certificate back to the DRAC. I did this via the DRAC5 web server. The certificate upload was confirmed successful. After this, port 443 was dead but the other ports were still working.

According to the post at the URL below, it should be possible to use self-signed certs so I assume there's something wrong with my generated cert even though it was accepted by the DRAC.

http://lists.us.dell.com/pipermail/linux-poweredge/2008-April/035852.html

/Håkan

PS. I have now been able to get port 443 back using _local racadm_.

I now seem to have a working web server with a custom certificate. I think I was getting confused by my own terminology. I had created a self signed cert instead of a cert signed by my own CA that I intended. The command line below resulted in a working cert:

> openssl x509 -req -in csr.txt -CA ca.crt -CAkey ca.key -out crt.txt

I had the same situation... after generating a csr and uploading the cert, I was not able to access the DRAC's web interface.  It pinged OK.  I knew it had to be related to the new SSL cert, since that was when the problem started.  I tried racadm racresetcfg, which did not help because as I found out it did not reset the ssl cert back to default/Dell-issued cert.  After some research I found a command to reset the ssl config and I tried racadm sslresetcfg, but got "ERROR: Unable to perform requested operation.  If the operation attempted was to configure DRAC, possible reason may be that Local Configuration using RACADM is disabled"  I figured sslresetcfg was not a valid command on this particlar DRAC (M600 blade server.)

I figured maybe there was a problem with the cert upload, and it was not able to use the new cert, so I re-uploaded the cert.  THAT WORKED and I was then able to access the web interface.  The cmd for this is:

racadm sslcertupload -t 1 -f

I have the same issue.

But what i saw is the valid to date of the uploaded cert has been changed, the original cert is valid to 04-03-19 the cert at the drac is valid to 08-21-25 (today)

So what's going wrong?

I uploaded my valid wildcard certificate issued by external CA (which works on any webserver)

Uploaded as .pfx supplying the password.

On reboot I only got error

SEC_ERROR_INADEQUATE_KEY_USAGE

In the end followed instructions from here:

https://www.dell.com/community/Systems-Management-General/Ignore-CSR-for-installing-wildcard-certificate-in-IDRAC6/m-p/3880293#M15272

Just remember that your.key is with NO passphrase as done by openssl

openssl rsa -in key.pem -out key_nopass.pem

edit

While that worked on one iDrac, on another (same model= iDRAC 9, same firmware = 3.30.30.30) it would not as each time it gave me

Security Alert: Certificate is invalid - Certificate is not signed by Trusted Third Party
Continuing execution. Use -S option for racadm to stop execution on certificate-related errors.
rc != 0ERROR: Unable to perform requested operation.

Well, that was the POINT of doing it, to get Certificate that IS signed by Trusted Third Party !!!

edit 2:

I believe the error was due to the fact that I did start previously a process of generating CSR and did not upload corresponding certificate.

Once done that, then I could upload my wildcard just fine.

So it probably means that CSR was still lurking & waiting for response hence racadm could not upload