Continuing from Part 1 of my VMware vCenter Certificate Automation tool, we are finally at the point where we can review what the built-in planner advises we do, and then replace our certificates. If you missed Part 1, go back and execute all of the steps or you have a better chance of a pig flying by your window and waiving at you than getting new SSL certificates working.
1. In case things go Tango Uniform, I strongly urge you do a full backup of all vCenter databases (SSO, vCenter, and VUM), plus snapshot/backup your vCenter VM(s). If you hose up the certificate replacement process you may be left with a smoking vCenter hole. Backup before proceeding!
2. On your vCenter server run the ssl-updater.bat script. They have a built-in planner which tells you which steps to perform and in what order, depending on what services you want to update. To access the planner type 1.
3. Since we want to update all our services, I pressed 8.
The result of pressing 8, was the following text:
1. Go to the machine with Single Sign-On installed and – Update the Single Sign-On SSL certificate.
2. Go to the machine with Inventory Service installed and – Update Inventory Service trust to Single Sign-On.
3. Go to the machine with Inventory Service installed and – Update the Inventory  Service SSL certificate.
4. Go to the machine with vCenter Server installed and – Update vCenter Server trust to Single Sign-On.
5. Go to the machine with vCenter Server installed and – Update the vCenter Server SSL certificate.
6. Go to the machine with vCenter Server installed and – Update vCenter Server trust to Inventory Service.
7. Go to the machine with Inventory Service installed and – Update the Inventory  Service trust to vCenter Server.
8. Go to the machine with vCenter Orchestrator installed and – Update vCenter Or chestrator trust to Single Sign-On.
9. Go to the machine with vCenter Orchestrator installed and – Update vCenter Or chestrator trust to vCenter Server.
10. Go to the machine with vCenter Orchestrator installed and – Update the vCenter Orchestrator SSL certificate.
11. Go to the machine with vSphere Web Client installed and – Update vSphere Web  Client trust to Single Sign-On.
12. Go to the machine with vSphere Web Client installed and – Update vSphere Web  Client trust to Inventory Service.
13. Go to the machine with vSphere Web Client installed and – Update vSphere Web  Client trust to vCenter Server.
14. Go to the machine with vSphere Web Client installed and – Update the vSphere  Web Client SSL certificate.
15. Go to the machine with Log Browser installed and – Update the Log Browser trust to Single Sign-On.
16. Go to the machine with Log Browser installed and – Update the Log Browser SSL certificate.
17. Go to the machine with vSphere Update Manager installed and – Update the vSphere Update Manager SSL certificate.
18. Go to the machine with vSphere Update Manager installed and – Update vSphere Update Manager trust to vCenter Server.
As you can see, we have to perform 18 steps to fully update all SSL certificates. Due to the “Known Issues” with VUM and using a FQDN, I shall not be performing steps 17-18 since that is not a supported configuration.
4. Getting back to the main menu by pressing 9, I now want to start updating the SSL certificates in the prescribed order per the pre-planner. So I press 2 to start with SSO.
To perform the certificate update I press 1. At this point you can opt to sacrifice a chicken over your vCenter VM to appease the SSL gods and make this go smoother.
After pressing 1 it then asks me where my SSO SSL chain file is stored. And it also wants to know where the SSO private key is, as well. Since we previously configured the environment script, the paths and files it listed were correct. I then typed in my SSO master password (you do remember it, right?). My install did not involve load balancers, so I told the installer no.
At this point the black magic starts, and my heart was thumping hoping that my chicken sacrifice worked. And a minute later….all seems to be well. Chicken worked!
Step 1 of the pre-planning guide is complete. Check!
5. Now that the SSO certificate appears to be successfully updated, it’s time to march on to the inventory service. So I press 3 to return to the main menu. On the main menu I press 3 to update the inventory service. I’m now presented with a plethora of options.
Per the pre-planning guide I need to select option 1. After 30 seconds of disk activity, I get a successful message.
Step 2 of the pre-planning guide is complete. Check! 16 left to go.
6. Slightly illogically the next step is to select option 3, per the pre-planning guide. Again, the certificate paths and files are pre-populated and are correct. Now it wants to know the SSO administrator user. If you aren’t sure what this is, open the Web Client and login. If you can access and modify the Sign-On and Discovery settings, you probably have the right username. In my case this is “sysadmin”, but it will surely be different for you.
A little whirring of my disk drive, and I get a successful message.
Step 3 of the pre-planning guide is complete. Check! 15 left to go.
Next up in Part 3Â is continuing the march towards completing all 18 steps by updating the vCenter and Orchestrator certificates.
Hi, when using the automation tool trying to update the SSO certificate I end up with the following error. [.] ERROR: One or more required parameters are not set or have invalid values: [.] – Certificate chain is incomplete: the root authority certificate is not p resent and cannot be detected automatically. The presence of the root certificat e is required so the other service can establish trust to this service. Try addi ng the authority certificate manually. Obviously I messed something up trying to create the chain.pem files. I'm guessing in your script where Set CA_Cert_Path=c:certsroot64.cer is set I… Read more »
Addendum, it appears the chain.pem is actually. So as near as I can tell the only step I missed is the chicken sacrifice.
Hi Derek,
Thanks for your step by step details and don't have issue to create sso certificate with your script from our internal microsoft CA; however, when i update sso certificate with vmware automation tools, goth the error: one or more required parameters are not set or have invalid calues:- the certificate chain file does not contaion valid certificate path. pkix path validation failed wit:certificate has unsupported critical extension <at certificate #1>. i create vmwaressl template on our microsoft ca server (windows 2003 ent version). any ideas? thanks.
I've seen that error myself when I had the certs in the wrong order in the chain.pem file. The order should be service cert on top, intermediate in the middle, and root on the bottom.
Anyone know how to do this when using a different name for the cert? My server name is server.domain.com, but I want to use vcenter.differentdomain.com. I tried adding the computer name to the SAN and leaving vcenter.differentdomain.com as the common name, but still get…
[.] ERROR: The leaf certificate doesn't have any CN or subjectAltName that match
es the public address of the current machine. Rejecting the chain. To skip this
check, set the `ssl_tool_no_cert_san_check' environment variable to 1.
I know this probably doesn't help you Joe, but if anyone else runs into this, there are a couple potential causes.
In your case, you can just type "set ssl_tool_no_cert_san_check=1" from the elevated cmd prompt just before running the tool, or add that line to the ssl-environment.bat script before running it.
Also, if you've broken out your vCenter services across multiple servers, and you attempt to replace a certificate for a service that isn't local, it'll throw this warning. I just ran the tool from each respective server.
upgraded SSO cert fine, when attempting to upgrade the Inventory Service cert I get the following error: "openssl.exe Cannot generate Inventory Service rui.pfx – errorlevel is 1"
any ideas?
I am having the exact same problem. I haven't found a solution yet…
Jeffrey, any solution to this? I am having the same issue.
Did you figure out this problem's solution? I'm getting the same error message. I tried re-creating the chain.pem making sure there were no extra spaces and got the same error. Any help would be appreciated!
I had this problem. Check the formatting of the certificate file or tne your .pem file. Make sure there now hidden spaces or that the characters are not out of alignment. That worked for me.
upgraded SSO cert fine, when attempting to upgrade the Inventory Service cert I get the following error: "openssl.exe Cannot generate Inventory Service rui.pfx – errorlevel is 1"
Jeffrey, did you get this resolved? I am seeing the same thing.
good news, and again, hopefully this helps someone. For reasons unbeknownst to me, my first attempt at updating the SSO SSL certificate went darn near the entire process. I was too dumb to write down the actual error, but basically everything was successful until the very end… something about LS backup data not being present. It turns out that it hand pretty much finished handing off the SSL cert, but didn't know what to do with it? Who is to say… Also after checking, my lookupservice was giving me a 404 error now! I used the rollback option and it… Read more »
Hi Derek I have used the SSL Automation Tool 20+ times for different customers and its always worked perfectly. I now have a customer with a VCE environment, and they have implemented a distributed architecture with SSO, vCenter and VUM on dedicated servers. I am thinking about my approacg to this, and I already envisage isses, as to run the SSL Tool the vCenter JRE needs to be on the server… When I run the tool on the dedicated SSO server it will not have vCenter JRE! Do you know a workaround, other than resort back to the manual replacement,… Read more »
Sean,
Thanks for the feedback. Yes a distributed environment makes it harder. My suggestion would be to stand up a scratch VM, install vCenter in a standalone mode (don't connect to existing SSO domain, etc.) and run the tool using the appropriate hostnames. Then copy the certificate files to the various machines and use the VMware tool to do the replacement. Kind of a hack, but I would think should work. Or just use an existing all in one vCenter VM to run the tool on. The latest version of my toolkit lets you specify hostnames for the services.