Users Guide

Login Type Certicate Type How to Obtain
SHA-2 certicates are also supported.
Local User login SSL Certicate Generate a CSR and get it signed from a
trusted CA
NOTE: iDRAC ships with a default
self-signed SSL server certicate.
The iDRAC Web server, Virtual
Media, and Virtual Console use this
certicate.
SHA-2 certicates are also supported.
Related links
SSL server certicates
Generating a new certicate signing request
SSL server certicates
iDRAC includes a web server that is congured to use the industry-standard SSL security protocol to transfer encrypted data over a
network. An SSL encryption option is provided to disable weak ciphers. Built upon asymmetric encryption technology, SSL is widely
accepted for providing authenticated and encrypted communication between clients and servers to prevent eavesdropping across a
network.
An SSL-enabled system can perform the following tasks:
Authenticate itself to an SSL-enabled client
Allow the two systems to establish an encrypted connection
NOTE: If SSL encryption is set to 256-bit or higher, the cryptography settings for your virtual machine environment
(JVM, IcedTea) may require installing the Unlimited Strength Java Cryptography Extension Policy Files to permit usage of
iDRAC plugins such as vConsole with this level of encryption. For information about installing the policy les, see the
documentation for Java.
iDRAC Web server has a Dell self-signed unique SSL digital certicate by default. You can replace the default SSL certicate with a
certicate signed by a well-known Certicate Authority (CA). A Certicate Authority is a business entity that is recognized in the
Information Technology industry for meeting high standards of reliable screening, identication, and other important security criteria.
Examples of CAs include Thawte and VeriSign. To initiate the process of obtaining a CA-signed certicate, use either iDRAC Web
interface or RACADM interface to generate a Certicate Signing Request (CSR) with your company’s information. Then, submit the
generated CSR to a CA such as VeriSign or Thawte. The CA can be a root CA or an intermediate CA. After you receive the CA-
signed SSL certicate, upload this to iDRAC.
For each iDRAC to be trusted by the management station, that iDRAC’s SSL certicate must be placed in the management station’s
certicate store. Once the SSL certicate is installed on the management stations, supported browsers can access iDRAC without
certicate warnings.
You can also upload a custom signing certicate to sign the SSL certicate, rather than relying on the default signing certicate for
this function. By importing one custom signing certicate into all management stations, all the iDRACs using the custom signing
certicate are trusted. If a custom signing certicate is uploaded when a custom SSL certicate is already in-use, then the custom
SSL certicate is disabled and a one-time auto-generated SSL certicate, signed with the custom signing certicate, is used. You
can download the custom signing certicate (without the private key). You can also delete an existing custom signing certicate.
After deleting the custom signing certicate, iDRAC resets and auto-generates a new self-signed SSL certicate. If a self-signed
certicate is regenerated, then the trust must be re-established between that iDRAC and the management workstation. Auto-
generated SSL certicates are self-signed and have an expiration date of seven years and one day and a start date of one day in the
past (for dierent time zone settings on management stations and the iDRAC).
The iDRAC Web server SSL certicate supports the asterisk character (*) as part of the left-most component of the Common
Name when generating a Certicate Signing Request (CSR). For example, *.qa.com, or *.company.qa.com. This is called a wildcard
93