Problems with GoDaddy Cert and SCCM SP1 - cannot get a .pfx file for my life

[SWood7]

Pulling my hair out on this one. Just got a GoDaddy SSL cert to provision my SCCM SP1 client HP Vpro machines. Followed the SCCM help file instructions to import the cert in to the member server's (my SCCM site server) local computer personal cert store. This went ok. The next step was to export the cert to a .pfx file format for use in the SCCM OOB configuration. For whatever reason, the export cert wizard does not allow you to export to a .pfx format, the only allowable formats are .CER and .P7B. Is there any trick to getting the cert in a format that SCCM can use?

[SWood7]

Well, I've hit a brick wall with my attempts to get vPro and SCCM configured. Microsoft want's a .pfx file and the GoDaddy cert will not export itself to this format. Speaking to GoDaddy, I need to look into OpenSSL to convert the GoDaddy cert to a .pfx file that Microsoft can consume. I'm digging into it right now but admittedly it's a bit over my head. If there are any OpenSSL gurus out there that could lend a hand, I'd be forever greatful. It's so frustrating with 800 vPro machines out there going nowhere.

[SWood7]

Well, I'm a bit farther down the line. I was able to create a .pfx file from OpenSSL with the included makepfx.bat file included with the program. I was able to use this file to configure my SCCM server.

Now I"ve got a server log full of

Error: Hash list of AMT device <guid> doesn't contain our provision server certificate hash.

This shows up every minute or so, presumably every vPro system is phoning home and wanting to be let in.

Now I've got to figure out how the heck the hashes don't match! Why is this so hard? (Or why am I so dumb?)

[idata]

Sorry for the basic question... but do you know that the Dell's you have contain GoDaddy as an available cert vendor in the MEBx list? I know that OEM's can choose from several different cert vendors. I don't have my Dell 755 up in front of me, or I'd check, but that's the first thing that comes to mind for me...

Dave

[SWood7]

No, basic is good for me! I've got HP 7800 Ultra Slim systems and the first batch that we got in had GoDaddy hashes in them. Now that you mention it, they may have pulled the GoDaddy hashes since then. I'll go look at a few machines and see if I can find the hashes.

[SWood7]

Did some leg work and found that all the systems I checked had a Go Daddy Class 2 CA in them. I wrote down the hash and now I guess I need to find the corressponding server-side hash for Go Daddy.

[SWood7]

Well I'm throwing in the towell on this one. I'm going to open a ticket with Microsoft and see if they can help me untangle this mess. The Go Daddy side looks ok. I've noticed their cert has the hash in it, however after I import it into my Microsoft site server, the hash / thumbprint mysteriously changes. I'm getting messages messages in my ConfigMgr site server for every AMT system

Error: Hash list of AMT device <guid> doesn't contain our provision server certificate hash.

The road goes on forever and the party never ends.

[Matthew_R_Intel]

It is highly unlikely that the GoDaddy certificate hash has been removed; it's part of the standard firmware build.

Let me see if I can walk you through this...

Assuming that your provisioning certificate you got from GoDaddy is in your personal certificate store?

1. If so, right click on the provisioning certificate and click "Export"

   Click "Next" and when presented with the option to export private yes, ensure you click "Yes" On the Export File Format, select "Personal Information Exchange". And ensure you check the following options.

2. Include all certificates in the certificate path if possible

3. Enable strong protection

4. Click Next

5. When presented with the password screen, give it a strong password.

6. In the file Name Field, select a location to save it click Next then finish.

7. With this freshly exported certificate, use this to import into SCCM.

Let me known if you are still having problems.

--Matt Royer

[SWood7]

Good morning Matt!

Ok, I've got the cert file, the *.crt file and I've imported it into my Config Mgr site server local personal store. If I try to "Export" it, by right-clicking on it, the wizard does not allow me to choose the "Personal Information Exchange" option, it's greyed out. To get around this, I used some instructions from a very good post ( http://communities.intel.com/message/1855 ) on openssl that have you copy your *.crt file to a *.pem file and then run makepfx.bat which creates a nice .pfx file for you.

Once I had the *.pfx file I could then pop it into the Configmgr OOB component configuration.

Just a few minutes ago, I got off the phone with Go Daddy after discussing a odd cert chaining issue I ran into. In trying to trouble shoot the errors I was getting in the ConfigMrg amtopmgr.log about provisioning server hash mis-matches, I looked at the certs that I downloaded. First I looked at the freshly downloaded cert, *.crt file and saw that the root CA was "Go Daddy Class 2 Certification Authority" and the hash at that level matched the AMT BIOS hash. Then I imported that cert into my site server's local computer personal store. I looked at the cert from that side and saw that the root CA was now "ValiCert Class 2 Policy Validation Authority". I thought to myself, viola! that must be the problem, I must have done something wrong in the import. However, Go Daddy informed me that the Valicert root was correct, they were still using it. I asked them if there wasn't any way to remove the chain so my vPro / AMT / ConfigMgr world could work right and he said he didn't know and that my best bet was to send an email to ra@godaddy.com and they'll pass it on to their developers for further review.

Have you run into this issue in your Config Mgr endeavors?

By the way, I like the youtube videos you've put together - they've really helped to visualize the whole process for folks like me. Keep 'em coming! Are they sound-less or is it just me?

[SWood7]

I spoke with GoDaddy again about the Valicert issue and they said there wasn't anything they could do to change the root cert behavior. They did say it was supposed to work though. They couldn't say how but they thought they heard it could work. Do you know anyone out there who is using a GoDaddy cert with SCCM SP1?

[SWood7]

Well, the latest update on my issue (like anyone cares but me - you all have to listen anyway!) is that Go Daddy is looking into tweaking their Root CA to that the Varicert Root is not chained to the Go Daddy CA. Hopefully this will make my Config Mgr OOB site provisioning server happy when it can see just the Go Daddy Calss 2 CA instead of the Varicert CA. Stay tuned!

[Matthew_R_Intel]

yes, please do... Out of curiousity, did you used the following process to procure the certificate from GoDaddy? p-10957 http://communities.intel.com/openport/blogs/proexpert/2008/03/03/steps-to-purchase-a-godaddy-certificate-for-the-purpose-of-vpro-remote-configuration

Just wondering if there is a series of steps that should be avoided that lead to the root of your issue.

--Matt Royer

[SWood7]

Yes, I did in fact. That document was the impetus to go forward with GoDaddy in the first place for us. The steps in purchasing the cert look clean and straightforward. For me, it's what to do after getting the cert according to Microsoft. I think the SCCM docs need to be a bit tweaked. I think the instructions that come with SCCM / SP1 are still the SP1 beta docs for the most part.

The folks at Go Daddy have be pretty helpful. They've been holding my hand throughout the process and not snickering (at least that I know of!) at my total lack of PKI knowledge. Good organization and good people. They've given me some OpenSSL commands to run with to see if that fixes the SCCM issue and finally gets my vPro machines talking to my SCCM site.

[SWood7]

I just fininished running some new openssl commands in an attempt to get my SCCM server to see the correct GoDaddy hash. I re-keyed the cert with GoDaddy again and then ran

openssl pkcs12 -export -in godaddycert.crt -inkey myprvatekey.key -certfile gd_bundle.cer -out bundle.p12

This command created a new bundle.p12 (.pfx) for SCCM systems that I imported into my SCCM site server's local cert store. Unfortunatley it came in again with the Valicert Root CA instead of the GoDaddy Root CA so my SCCM server only recognizes the root Cert (this from my SCCM amtopmgr.log)

Get ROOT HASH of provision server 317A2AD07F2B335EF5A1C34E4B57E8B7D8F1FCA6.

this hash is the Valicert Root, not the GoDaddy Root.

I don't suppose there's a way to do this without PKI?

[William_Y_Intel]

I have setup a GoDaddy cert with my SCCM infrastucture and here are some notes to compare with your setup. When I open up the GoDaddy cert that was loaded into my Personal Cert store and view the chain of trust, I see the following:

Go Daddy Class 2 Certification Authority

-

> Go Daddy Secure Certification Authority

-

> Remote Configuration Certificate (this is my Remote Config I ordered and use on my SCCM server)

As you see in the above example, my cert is chained to the Go Daddy Class 2 Certification Authority which contains the thumbprint that is embedded in the firmware (27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4).

Also, this GoDaddy Root CA (Go Daddy Class 2 Certification Authority) is imported into my Trusted Root Certification Authorities Certificates store. Do you see this Root CA in your Trusted Root Certification Authorities Certificates (you might try both local computer and Current User).

Some how when you are importing the Remote Config cert, it is getting chained to the valicert, which would break the proper chain as this is not one of the supported external Root CA hashes. let me know if you have the aboved listed in your trusted root stores.

[SWood7]

I just downloaded a re-keyed cert this morning and imported it into my site server local store. After i import it the chain now looks like this...

http://www.valicet.com/

Go Daddy Class 2 Certification Authority

Go Daddy Secure Certification Authority

ocdasms001.da.ocgov.com

It looks the same if i import it into Intermediate Certificate Authorities. Were you able to export your .crt file into a .pfx file that SCCM could use for OOB management?

[MICHELE_G_Intel]

Hey there! Our SCCM quick start guide is going to be handed off to a writer for revision/fine tuning next week - any feedback that you have from a user point of view is soooo appreciated - please send comments on over to me! Thanks in advance

[SWood7]

I will be happy to add my input and suggestions.

[William_Y_Intel]

Can you remove the velicert certs from the trusted root store and try your process again? Just curious if these are messing up the import.

[SWood7]

That's a good idea! I'll give it a try and see if it does the trick. I've just gotten another custombundle.crt file from GoDaddy to try and it that doesn't work I'll see about doing away with the Valicert root!

Thanks!

[SWood7]

Problem solved ! Got a customized cert bundle from Go Daddy and it imported fine without the extra Valicert root chain I'm working and beginning to provision! I have a new issue now that has to do with dhcp but i'll start another thread on that one!