Home > ADCS, Dell, PKI, SSL > Configure Dell iDRAC to use Domain PKI

Configure Dell iDRAC to use Domain PKI

So my PKI works.  But…… I don’t know what to *DO* with PKI.  Maybe I can…. Oh hell who knows.  Wait.  Network Devices!  Things that have HTTP/HTTPS administration pages, with SSL errors.  YES!  Let’s start with that.  That seems like a good enough target.

1) Browse to HTTPS://NW-ESXi1-IDRAC(  Get an SSL error, but trust it.

Hold up.  You DID create a DNS name for the iDRAC right?  Because the Subject Name of the SSL, and the Host Header used, and the Host Name all have to match, we know this from basic IIS.  Go make your DNS entries now.  I’ll wait.  Good.  Should have done that ages ago anyway…

2) Click on SYSTEM -> REMOTE ACCESS on the left.  Then CERTIFICATION tab.  Then SSL option.


Click GENERATE A NEW CERTIFICATE SIGNING REQUEST (CSR) and click NEXT.  NOTE the red bar showing the Certificate Error!

3)  Enter your CSR Information:


Remember the Common Name should be your host name (not FQDN).  Your Organization name has strict requirements as to what it can contain – I think it is alpha numeric and – and _.  To simplify my life, I never use “NetWise Inc” or similar, just make it NetWise.  City and State should be filled out in full.  E-mail is optional, I’d exclude it (scratch that, got an error demanding it as I was doing this for screen shots).  Click GENERATE.

4) clip_image006

Note that it wants to call it “CSR.TXT”.  This is stupid.  Save it somewhere that is shared between where you are doing this configuration and the Subordinate CA (NW-ADCS1).


I might suggest a shared/common network location that the Administrator has access to, and rename it something with a little bit more detail.  Something like <COMMON NAME>.csr.txt.  Don’t get fancy and drop the .txt, you’ll see why later!

5) Go to  your Subordinate CA and login as a user who is member of ENTERPRISE ADMINS.  This is going to burn you sooner or later, as many accounts you use for Domain Admins are NOT part of Enterprise Admins.   Open the Certification Authority from the Admin Tools.  Expand everything nicely:


Right click on the CA (NW-ADCS1-CA) and choose ALL TASKS -> SUBMIT NEW REQUEST


Select your CSR.  Remember how I said don’t drop the .TXT?  Look at the types – *.req; *.txt; *.cmc, etc.  I don’t have Explorer set to show extensions which is why you don’t see NW-ESXi2-iDRAC.csr.txt.  But if you changed the name, you’ll not find your CSR, which is frustrating at the end of a long night of fighting with this.


Select your CSR and click OPEN.

6) What the hell?  Why is there an error????


http://pdconsec.net/blogs/davidr/archive/2008/08/13/No_2D00_Certificate_2D00_Template_2D00_In_2D00_Request.aspx– and I quote:

===== QUOTE =====

Microsoft’s resolution: Generate the request some other way.

Stuff that.

Dave’s solution:

certreq -submit -attrib “CertificateTemplate: WebServer” WebServerCertReq.txt

The key is the extra attribute we add to force use of the template. The certificate is issued and we can go and import it to the web server.

===== QUOTE =====

Okay, well I can live with that .  Let’s open a command prompt and do that.  File is on M:\CA where I saved it:


When you run it, you’ll get this pop up.  I don’t yet know why.  I THINK it is because the PKI setup I used said to follow all the instructions on, says to remove the LDAP:// URI.  You can see from the command prompt behind that it is showing LDAP:.  Just pick the second one, as right now my HTTPS version seems to not bet working.  Click OK.


Save the file.  Something good like <HOSTNAME>.cer, as suggested.  Type is X.509 Certificate.  Click SAVE

7) Go back to the iDRAC configuration web page.  It’s probably timed out – so relogin and Click on SYSTEM -> REMOTE ACCESS on the left.  Then CERTIFICATION tab.  Then SSL option.




Browse to your new CER file.  If you’re not sure, it will be the one with the hostname, but the later timestamp.  Select it and click OPEN.


Click APPLY and then click OK on this message.  It WILL take 2-4 minutes before you can log back in.  It wants to close the tab, and you probably should.

8) Open a NEW BROWSER and browse to the site – would you look at that – NO SSL ERROR.


This assumes that if you did all the stuff in my previous PKI post (https://vnetwise.wordpress.com/2012/05/19/enterprise-ca-pki-for-domains-2-tier-with-root-subordinate/) to set up the Root CA and Subordinate CA, with GPO options, that you are doing this later on, on a computer that has refreshed its GPO’s, to get the trusted Root and Intermediary CA’s for your network.  If you have NOT, then you SHOULD EXPECT to get an SSL error here, as it has no idea that it should trust the Subordinate CA that just issued your certificate.  This ALSO means that if you have a non-domain computer such as a personal laptop that you bring to the office, you SHOULD EXPECT to get SSL errors, unless you have told it to trust your ROOT/Subordinate as well.  This CAN be done, but it is WAY out of scope for this.

Categories: ADCS, Dell, PKI, SSL
  1. February 24, 2013 at 12:38 AM

    I’ll right away snatch your rss as I can’t find your
    email subscription link or newsletter service. Do you have any?
    Please permit me realize in order that I could
    subscribe. Thanks.

  2. Ian
    April 20, 2015 at 9:36 AM

    Your link for setting up PKI with GPO options located here is broken –


    Can you fix this?

    • April 20, 2015 at 9:39 AM

      Sure. I just checked them and they appear to be working. Which one is giving you grief?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: