PowerEdge: Custom SSL Certificate Deleted After iDRAC9 Firmware Update

iDRAC Web Server certificate is reset to self-signed after firmware update of 6.10.80.00 or newer. 

Before Update - Custom Certificate 

[root@ans ~]# curl -svik -X GET https://192.168.10.81 2>&1 | grep -iA5 "Server certificate"
* Server certificate:
*  subject: [NONE]
*  start date: Apr 15 19:04:44 2022 GMT
*  expire date: Apr 14 19:04:44 2024 GMT
*  issuer: DC=local; DC=sumers; CN=sumers-WSUS001-CA
*  SSL certificate verify ok.

After Update - Regenerated Self-Signed Certificate

[root@ans ~]# curl -svik -X GET https://192.168.10.81 2>&1 | grep -iA5 "Server certificate"
* Server certificate:
*  subject: C=US; ST=Texas; L=Round Rock; O=Dell Inc.; OU=Remote Access Group; CN=idrac-7wv0xk2; emailAddress=support@dell.com
*  start date: Jul 11 07:59:00 2023 GMT
*  expire date: Jul 12 07:59:00 2033 GMT
*  issuer: C=US; ST=Texas; L=Round Rock; O=Dell Inc.; OU=Remote Access Group; CN=idrac-7wv0xk2; emailAddress=support@dell.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.

When idrac.os-bmcadminstate is enabled (USBNIC), Dell check if the rceserver certificate exists.

This rceserver cert is used by the rceserver, an internal iDRAC process responsible for listener sockets that are used with iSM communication.

When this certificate does not exist or if it is expired we regenerate that certificate.

This creation of the rceserver certificate was overwriting the certificate type flag in pre 6.10.80.00 firmware to indicate that a self-signed certificate in use.

On every iDRACreboot, the webserver certificate is re-validated.

These validation checks verify that the certificate and key is available, not corrupted.

If the certificate type flag indicates that a (default) self-signed certificate is in use, then additional checks run which verify that the certificate number (CN) matches the idrac.nic.dnsracname attribute.

Should the CN does not match the dnsracname then we regenerate a new self-signed certificate for the webserver.

A customer can run into this issue when the following sequence of events occurs:

1. A custom Web Server certificate has been uploaded to iDRAC9.
2. iDRAC9 is on a pre 6.10.80.00 firmware version when the rceserver cert gets created/re-created. This is triggered using USBNIC enablement.
   Note: Rceserver cert is only created on first enablement of usb nic, and it will only be re-created if it is expired which is set for 1 year.
3. iDRAC9 Firmware is updated to 6.10.80.00 or higher AND the Custom Certificate CN does not match the idrac.nic.dnsracname attribute

If a customer hits this issue, they must reupload their Custom Certificate. The root cause has been addressed in iDRAC9 6.10.80.00 and above the rceserver cert creation no longer touches the internal certificate type flag that could lead to the issue. 

iDRAC9 firmware for 15/16G version 7.00.60.00 completely mitigates the issue even if certflag was incorrect. 
iDRAC9 firmware for 14G version 7.00.00.171 completely mitigates the issue even if certflag was incorrect. 

Workarounds
Before upgrading iDRAC9 from firmware which is older than 6.10.80.00 to versions less than 7.00.60.00 the option can enable/disable the USB NIC "Twice" which mitigates the issue. 
 

$ racadm set idrac.os-bmc.adminstate 0
$ racadm set idrac.os-bmc.adminstate 1
$ racadm set idrac.os-bmc.adminstate 0

$ racadm set idrac.os-bmc.adminstate 0
$ racadm set idrac.os-bmc.adminstate 1
$ racadm set idrac.os-bmc.adminstate 0