From last 2 days I was working on using signed certificates for my vSphere lab and was determined to replace my self-signed certificate with signed certificate generated by my CA server.
I have written a blog post on how to setup CA server and how to generate signed certificates and how to replace them. If you have missed earlier post of this series you can read them from below links:
I must say this journey of learning use of signed SSL certificates were not easy for me and I did made a few mistakes before setting everything up right. But I guess it was for my own good that I made these mistakes because then I had to do a lot of troubleshooting to set things correctly and learned quite few things while doing so.
I am going to cover a few mistakes which we should avoid while working with SSL certificates:
Mistake-1: Use of SHA-1 algorithm while setting up CA Server
While I was installing CA server role there came a point where I had to select the hashing algorithm and I went with default SHA-1 as visible in below screenshot.
Due to this, after generating and replacing my vSphere Certificate when I was accessing the vCenter Web-Client console. it was showing that certificate has been generated by my CA server but the authenticity of website can not be verified and still the certificate was showing as red.
Also you can see the certificate is showing warning related to use of weak SHA-1 hashing algorithm.
The reason for this was I was using google chrome and Google released a new policy some times back to degrade websites that utilize a SHA-1 Certificate in its user interface for chrome version 39.
You can read more about this from below links:
How to troubleshoot this?
To counter this issue you have to change the hashing algorithm for you CA server and have to use SHA-256. This can be done by using the below commands:
# certutil -setreg ca\csp\CNGHashAlgorithm SHA256
# net stop certsvc
# net start certsvc
After this generate the certificates again and replace the certificates one more time.
Once I had followed the above steps everything worked like a charm.
Mistake 2: Use of old vCenter Certificate Automation Tool
I am running vSphere v5.5 update 2d in my lab and for automating SSL certificates I downloaded the old version (1.0.x) of Certificate Automation Tool unknowingly (may be I was very excited and did not checked the appropriate version of this tool in my sheer excitement)
Due to this when I was running the command to update my SSO SSL certificate, this tool was failing with error that it cannot find SSO service installed on my system. I was running the tool on same server where my vCenter Server (all components) was installed.
After trying for 3-4 times I was scratching my head what can be the issue as I have verified that SSO service is installed correctly on my server. After a while I googled again and found new version of this tool for vSphere 5.5.
I downloaded the new version and this time when I run the command to update SSO SSL certificates it completed without any error.
Mistake 3: Not following all the steps generated as part of action plan by Certificate Automation Tool
When you run the SSL tool for the first time it will ask you to prepare the steps needed to replace SSL certificates in right order as visible in below screenshot.
I wanted to update SSL certificates for SSO, Inventory, vCenter and web-Client so this tool laid out action plan for me as below:
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 Orchestrator trust to Single Sign-On.
9. Go to the machine with vCenter Orchestrator installed and – Update vCenter Orchestrator trust to vCenter Server.
10. Go to the machine with vSphere Web Client installed and – Update vSphere Web Client trust to Single Sign-On.
11. Go to the machine with vSphere Web Client installed and – Update vSphere WebClient trust to Inventory Service.
12. Go to the machine with vSphere Web Client installed and – Update vSphere WebClient trust to vCenter Server.
13. Go to the machine with vSphere Web Client installed and – Update the vSphere Web Client SSL certificate.
14. Go to the machine with Log Browser installed and – Update the Log Browser trust to Single Sign-On.
15. Go to the machine with vSphere Update Manager installed and – Update vSphere Update Manager trust to vCenter Server.
When first time I ran this tool I missed steps 8,9,14,15 thinking that vCenter Orchestrator and Log browser service is not installed in my lab. You must say I doubted the tool for generating steps related to orchestrator and log browser. This was my mistake.
This tool is intelligent enough to produce correct steps for replacing SSL certs in a right way and we should adhere to this steps. Next time when I ran this tool again I followed all the steps generated as part of action plan and everything went well.
I guess sometimes its good we do mistakes as it teaches us a lot of other things (during researching troubleshooting steps) which are not directly related to our issue.
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable 🙂