Upgrading vCenter 5.5 SSL’s to public CA-issued certs

Posted on

Well, I started out writing this article with the expectation that I’d be providing a solution to the world after figuring it out myself, and at this point I’ve given up.  As best I can tell, there is no way to use SSL certs issued by a public CA in vCenter.  There are two reasons for this:

  1. I have not found any public certificate authority who issues a certificate that preserves your original Organizational Unit (OU) field from your certificate signing request (CSR).  vCenter and all its associated services, when using SSL’s you’ve provided, requires each of the SSL’s to have a unique Distinguished Name (DN), and the DN is made up of the Common Name (CN) and the OU.Most SSL providers strip the OU completely, so now, each of your certs for the various vCenter services (vCenter, vCenter web client, Orchestrator, Inventory, Updater), which are REQUIRED to have a unique OU, no longer have a unique OU.

    Some providers, like GeoTrust, who do not strip the OU, replace your CSR’s OU with their own crap, like:

    OU=See http://www.geotrust.com/resources/cps (c)15, OU=Domain Control Validated – QuickSSL(R)

    Without a unique OU, your configuration of the vCenter Trust to Inventory Service step in updating certs will fail with “Cannot register vCenter with Inventory Service: 7”

    VMware notes this failure is because of “This issue can occur if the certificates were generated with a misconfigured subject template on the certificate authority or the certificate is missing expected OU information.” in article https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2102685

    Well of course it’s missing required OU info, GeoTrust stripped it out.

    If anyone can find a public CA who preserves the original OU from the CSR, please let me know as I’d prefer to run vCenter with certs recognized by any software I choose to try talking to it with without special root cert importing, etc.

  2. Second issue, let’s say your vCenter install is on a server named vcenter1.mycompany.com (or vcenter1 for short), with IP address 192.0.2.1.  Well, the other part of your certificate generation process will be the incorporation of a Subject Alternate Name (SAN) field in your CSR.  The SAN field, as generated by the vCenter SSL Certificate Automation Tool 5.5, will include the FQDN, the short name and the IP.  From my reading, I believe these are necessary because not all services within vCenter talk to each other using a FQDN.  Alternatively, if you’re a Windows AD shop, you have probably give your servers some stupid name that doesn’t have an internet-resolvable FQDN, such as vcenter1.sanfrancisco.  In any case, no public CA will allow you to get a cert issued with a SAN field that contains a short name or a private IP, at least that I’ve found.  I’m not certain on whether or not they’ll even issue a cert with a CN and SAN that contain a FQDN that is not internet-resolvable.  It sounds like no based on this Comodo blog post related to industry standards https://blog.comodo.com/e-commerce/phase-ssl-certs-internal-names-reserved-ip/

So, either way, we’re screwed, and vCenter can’t run with public CA-issued certs.  If anyone has a workaround for this, would love to hear it and will promptly update this article.  If someone from VMware is reading this, thanks for wasting many hours of my time; I’m sure you’ll compensate me for it at the next license renewal…

 

Starting this article out with an excerpt from below: snapshot your vCenter server(!!!), change your vCenter login (possibly a Windows domain user) AND your SSO admin account password to something nice and weak before going any further.  This may be problematic if your vCenter server is set to log on as this user, in which case you should change the service properties as  well and then restart everything to ensure it’s stable.

Sections:

Well, as is typically the case with VMware as of late, and by late I guess we’ll just say the past five years, we’re presented with yet another clusterfuck of a situation with one broken way after another to attempt to solve it.  You know you’re in VMware-hell when you start with one kb article and next thing you know your browser has 20 tabs open from having to click through YAA (yet another article) to get to the starting point so you can back track through all the others.

 

Why am I putting public SSL’s on my vCenter?

In any case, I started my day wanting to upgrade a pre-existing vCenter 5.5 install to 6.0.  There is nothing too exciting about this setup; straight install Win2k8 R2 with 5.5, formerly 5.1, formerly 5.0.  Everything is on one server.  I snapshot the VM, start the installer, and it immediately bombs with:

The system name in the vCenter Server 5.5 SSL certificate and the vCenter Single Sign-On 5.5 SSL certificates are not compatible. Please replace either the vCenter Server SSL certificates or the vCenter Single Sign-On SSL certificates so both vCenter Server and vCenter Single Sign-On SSL certificates use the same system name.

Hmm okay, I’ve never customized this install in any particular way that you’d think would leave it with a non-standard config, but I guess we have some work to do.  I figure we may as well switch to ‘real’ SSL certs from a public CA, solve this problem and maybe solve other problems long term by not using self-generated certs.  I start digging around and find what sounds like the holy grail; the “SSL Certificate Automation Tool 5.5”.  Reading the kb article, you’d think VMware wanted to make my life easy and a few minutes later I’d be good to go…

Well you know how that goes.  The same people that brought us the SSL Certificate Automation Tool are apparently the ones that thought the web interface written in Flash was a fantastic idea.  The “tool” is really just a big batch file.  Yes, people still write those apparently.

 

Problems Encountered

So, before we go any further, here’s words of advice; snapshot your vCenter server(!!!), change your vCenter login (possibly a Windows domain user) AND your SSO admin account password to something nice and weak before going any further.  This may be problematic if your vCenter server is set to log on as this user, in which case you should change the service properties as  well and then restart everything to ensure it’s stable.  This piece of junk will leave your vCenter web interface unusable if you start the process with a good password, and the web interface is of course the only place to change the password to one you want to change it to.

In my case, what occurred is I began the process with a strong SSO admin pass.  I made it to the third step of the SSL update tool and it bombed out after asking me for the SSO admin pass.  My pass had an ampersand in it, so in the logs, you just get this:

[Mon 04/04/2016 – 12:22:29.80]: Unregistering Inventory Service from Single Sign-On …
& was unexpected at this time.

VMware’s happy article on how to resolve this issue is to change your SSO admin pass to something simple that has no special characters.  You know where you do this?  In the web client of course.  Try getting in there and you’ll instead get this:

Based on the current configuration, the SSL certificate of the authentication server was not trusted.

So great, I need to get into the web client to fix the SSL tool from breaking, and the SSL tool has broken the web client.  More digging, more kb articles.  Next step of the solution is start an admin command prompt on your vcenter server, cd to c:\program files\vmware\infrastructure\vmware\cis\vmdird\ and run the vdcadmintool

This will let you reset your administrator credentials.  Select option 3 for “reset account password” and give it the account DN of:  cd=Administrator,cn=users,dc=vSphere,dc=local

It will then spit out the new password it generated for you.  Here’s the funny part; more often than not, it will generate a password that contains characters that will break the SSO tool.  So just keep generating new ones until you get a magic password that is devoid of what VMware describes as “any special characters, such as &, ^, %, or <“.  Really, you can’t just give me the whole f’ing list?  I need some vague definition of special characters, “such as”….   I’ve found that quotes and spaces are not allowed, but backticks are, as are forward slashes.  So I just kept running the tool until I got a password that worked.  It didn’t fix the web interface, yet, but allowed me to keep going with the SSL tool.  Ultimately, I had to revert to snapshot anyway and start over, so just change your passwords to something stupid while doing this upgrade and maybe it will work first try.

Okay, getting back to why we’re here to begin with; installing public certs.

Pre-Req’s to using the SSL Certificate Automation Tool 5.5

So I’m not sure why, and I didn’t try to contradict VMware’s directions, but they want you to use six or seven unique certificates for your six or seven services (SSO, vCenter, web client, inventory, update manager, etc.).  They all must have unique OU’s, and all should have the IP, FQDN and short name as Subject Alternate Name entries.  Great, I get to purchase six certs instead of one.  At least certs are cheap these days.

You’re going to want to edit the ssl-environment.bat file to pre-define the location of all of your certs because chances are you’re going to be running and re-running the ssl-updater batch file over and over while you try to figure out what vmware wants you to do.  The “Chain” files each section refers to are not simply the CA certs, which you may have expected if you come from a web hosting background; the chain is your actual cert, the CA and (sometimes) the root for the certificate authority, so do not set the chain to be the same thing for each section as they will all be unique.

Use the SSL tool to generate all of your CSR’s.  It will end up doing the same info for each one with a unique OU.  If you set your ssl-environment.bat file correctly, you’ll have subdirectories for each section and all will end up with a rui.key and rui.csr file.  You take the csr to your certificate company and get back a signed cert.  In my case, I used RapidSSL because they’re cheap.  Oh yeah, the tool stupidly still generates SHA1 CSR’s, but most CA’s are only issuing SHA2 now, so just be careful if you use one who gives you back a SHA1 cert.

Now the fun part.  Finding the correct combination of CA and root to make the SSL tool happy.  I found the easiest way was to query a website I knew to be running the same type of cert I had been issued without error.  Use openssl for this:


openssl s_client -host DOMAIN -port 443 -prexit -showcerts

That will give you back something that includes this:

Certificate chain
0 s:/CN=DOMAIN
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
—–BEGIN CERTIFICATE—–
MIIEZzCCA0+gAwIBAgIQXs6/OBzH9aoismcC5ISE4jANBgkqhkiG9w0BAQsFADBC
…
bDdvP2Ji1PwLm5wC0kTw9KHjJpybBWyCQtJJ
—–END CERTIFICATE—–
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
—–BEGIN CERTIFICATE—–
MIIETTCCAzWgAwIBAgIDAjpxMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
…
2A==
—–END CERTIFICATE—–

You can take the ‘1’ cert, which is the intermediate (and you may have more than one) and cut and paste those directly into your CA cert file.  Unfortunately you’re not done.  VMware actually needs even the trusted root cert for one specific step, but not all.  In the above output you’ll see a reference to “i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA”.  That’s the one it wants.  I found that was available for download at https://www.geotrust.com/resources/root-certificates/.  So now I took that and kept it for when needed, which I’ll tell you.

This next part you’ll find far easier if you have a command prompt on a Mac or Linux box mounting your vCenter drive given you have to prep 6+ cert files.  You need to assemble the ‘chain’ file for each certificate for the SSL tool to import.  The chain file should be ordered as DOMAIN_CERT andCA_CERT, but not the ROOT cert yet.  They’re just pem format back to back no blank lines.  In my case, from Mac command prompt, I just did a “cat vmware-component/cert.txt rapidssl-ca.txt > vmware-component/chain.pem” for each of the six pieces that get their own cert, then when I was done, I had all six in their respective directories named chain.pem with all the right pieces.  The keys are all vmware-component/rui.key.  Keep that root cert around for later, I’ll let you know when you need it.

Now you can get back to the SSL tool menus.

Using the SSL Certificate Automation Tool

With your above pre-req’s done, now it’s time to use the tool to break update your vCenter install.  It is not intuitive, so I recommend you choose the option 1 of “Plan your steps to update SSL certificates(Update Steps Planner)”.  It will spit out the order in which you should do everything, just so you have confirmation you’re doing it right, and it makes it easy to know where you left off if you check off the items as you go in notepad, etc.  The following steps contain my original timeline, through multiple attempts so you’ll know where I went wrong, but have also been updated to reflect what needed to be set to do it right.

  • Start with SSO; update the SSL cert.  Done.
  • Time for inventory service trust to SSO.  This worked fine for me, however, the inventory service can take a VERY long time to restart if it’s been running for a while, so don’t assume something is hung and broken.  Mine took 25 minutes to restart the first time.
  • When you get to the step of “Update the vCenter Server Trust to Single Sign-On” this makes an odd request.  It will ask you for “Enter location to the new Single Sign-On SSL chain. If SSO is behind a Load Balancer, provide the Load Balancer CA certificate: “This is an odd one because up until now, the other requests have all asked for unique SSL chain files.  This one is asking for a chain file already created for the SSO service.  In this case, what it expects you to feed it is a single pem format file containing, in this order, the certificate you received for your SSO service, the CA/intermediate(s) and then the root.  So unlike the cert you fed to SSO to begin with, which was a chain file containing your host certificate plus the intermediate, you now need to modify that file and paste in the root cert for the issuer you used (GeoTrust in my case).  Go ahead and import that; should work.The first time I tried this, without the root, I got:ERROR The last certificate in the supplied certificate chain is not a self-signed authority certificate. Append the authority certificate to the chain file.
  • Next up, update vCenter Server SSL Cert.  This one starts out with a foreboding message: 
    Enter vCenter Server administrator password (will not be echoed):
"Important: Enter the password carefully. The Certificate Automation Update Tool does not check the validity of the vCenter Server database password."
"A blank or incorrect password will leave the system in an inconsistent state, which will cause the vCenter Server to become unavailable. "
"If the system becomes unstable due to a bad password, see the Troubleshooting Section of KB 2041600."
Enter the vCenter Server original database password (will not be echoed):

    Are you kidding me?  Hey, give us a password, we won’t bother to check that it’s correct before doing work, we won’t show it to you so you can confirm it was typed correctly, and you may break your entire install.  WTF is the original database password anyway?  Is that the SQL Server sa pass?  Some other random pass?  My vCenter runs as a service account that we created and SQL server is running in Windows auth mode, so what would the original password even have to do with anything?Well, first time I did this, I chose wrong and actually gave my original password, which blew up my vcenter.  I thought it worked, but then…

  • Update vCenter services trust; crunch “Cannot register vCenter with Inventory Service: 7”.   And now vCenter appears to be down.  KB article 2102685 suggests something is wrong with the OU of my certs, only the CSR’s were generated by this f’ing tool, so what now….
  • I ended up reverting my vCenter to the snapshot; just could not figure it out.  Starting over, changed my user and my SSO admin account passwords to weak ones.  On to attempt #2.
  • Starting over, this time I did my chain.pem file without the GeoTrust root, only with the actual server cert and the CA cert.  These were accepted up until the step of “Go to the machine with vCenter Server installed and – Update vCenter Server trust to Single Sign-On.” where I learned the root needs to be included (and updated the steps above).
  • Time for “5. Go to the machine with vCenter Server installed and – Update the vCenter Server SSL certificate.”  Oh joy, back to the step of having to give it the mystery database password you have no way to verify until it blows your fucking server up and you start over.  Guess I’ll take another snapshot.  I found this page where someone having the same issue (and the commenters) decided that “original database password” actually means whatever is currently used by the ODBC connection for vCenter to talk to the database.  Therefore, if you, like me, are using Windows authentication for your vCenter to talk to SQL Server, and that user happens to be the same one that the vCenter services are set to run as, then it does not want your original password, it wants the current password of the service account you’re using for vCenter to talk to the database.  The only time you’d actually be using original anything is if you created a SQL Server database user originally and that’s the account vCenter was using to talk to the database.  Okay, let’s try it: 
    If the system becomes unstable due to a bad password, see the Troubleshooting Section of KB 2041600.
Enter the vCenter Server original database password (will not be echoed):
Enter Single Sign-On Administrator user (default value is: Administrator@vsphere.local):
Enter Single Sign-On Administrator password (will not be echoed):

[.] The supplied certificate chain is valid.
Loading 'screen' into random state - done
Restarting services... (This can take some time)
Stopping vCenter Web Services...
Stopping vCenter Server...

    Oh man, holy shit, is it going to work this time?!?!?!?
    BOOM; worked!

    "Starting vCenter Server and other services..."
[Tue 04/05/2016 - 11:39:11.45]: Last operation update vCenter Server SSL certificate completed successfully.
[Tue 04/05/2016 - 11:39:11.46]: Go to the next step in the plan that was received from Update Steps Planner.
  • Okay, step 6, add vcenter trust to inventory.  Hey, screw you buddy, it’s not going to be that easy: 
    [Tue 04/05/2016 - 12:04:00.77]: The services that are restarted as a part of this operation are: VMware VirtualCenter Server, VMware VirtualCenter Management Webservices and VMware vSphere Profile-Driven Storage Service.

[Tue 04/05/2016 - 12:04:13.26]: Last operation update vCenter Server trust to Inventory Service failed :
[Tue 04/05/2016 - 12:04:13.27]: Cannot register vCenter with Inventory Service: 7
  • Umm okay, giving up now, appears to be an insurmountable issue with the DN of the certs; more info at top of article now that I’ve given up.

 

 

2 Replies to “Upgrading vCenter 5.5 SSL’s to public CA-issued certs”

  1. Tanny

    Holy crap. What a pain in the a55!!! This is the most convoluted process with a SQLexpress db and the system account. I am doing this on a physical with no snapshots.

    Reply ↓

Leave a Reply to Tanny Cancel reply

Your email address will not be published. Required fields are marked *