Replace Just Expired Self-Signed vCenter SSL Certificate – Part 2 of 3: Replacing

So we have already created the self-signed certificate via MS AD Certificate Service for the vCenter Server in the Part 1. In this second section we will replace the expired certificate using the chain.pem and rui.key files. Let’s do this with the VMware SSL Certificate Automation Tool!

Attempt #1

Start the ssl-updater.bat and select the option 5, then 2. That would have been the easiest and the normal method.


But, it couldn’t log in to the vCenter Server (Me neither manually via vSphere client). So got the following error message:

[2016.08.29. - 16:47:04,02]: "Cannot log in to vCenter."
[2016.08.29. - 16:47:04,03]: The vCenter certificate update failed.

Tried several times, also with another accounts, but same results. The Deploying and using the SSL Certificate Automation Tool 1.0.x (KB2041600) has a similar problem in the known issues section, but in our case the Managed Object Browser was not disabled. I have checked also the logs, but nothing helpful. Okay, we have to find another solution.

Attempt #2

Fortunately there is a KB exactly about this issue: Recovering from expired SSL Certificates in VMware vCenter Server 5.5 (KB2096030). I have done the steps 1-7, then with the step 8 for the following command:

ssolscli listServices

I got the message:

com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matched

Nice… There are various KBs about this issue, but nothing useful.

Attempt #3

It’s not the most beautiful solution, I know, but let’s change the date and time of the vCenter server. The certificate was valid till 27th of Aug, 2016, so I selected the 26th of August. Finally I could login into the vCenter via the vSphere client. Okay let’s try to replace the certificate with the SSL Certificate Automation Tool, as in the Attempt #1. In this case the tool could login to the vCenter, but I got a new error message:


2016-08-26T15:15:13.935+0200 [c.v.s.c.ValidateChainMain] ERROR The certificate chain file does not contain a valid certification path. PKIX path validation failed with: Could not validate certificate: certificate not valid till 20160829155832GMT+00:00 (at certificate #1)
2016-08-26T15:15:13.935+0200 [c.v.s.c.ValidateChainMain] ERROR The supplied certificate chain is not valid.

I thought, that something is wrong with the certificate, so re-crated very carefully 2 times – same results. It should have been OK, but… it didn’t work.

Attempt #4

What if, I change the date and time of the MS AD Certificate Service server? That is a Windows 2008 R2, let’s try it. I used the same date: 26th of August. Afterwards I have tried to create a new certificate again, but the MS ADCS webpage wasn’t even available. Interesting, what happened? Changed back the date – everything back to normal. I have checked the events and logs in the Windows server and founded the following from the CertificateAuthority:

08-vrootca-time-drift-cannot-loginGotcha!! So there was a date/time drift between the MS ADCS and the MS AD. That’s true. Let’s change the date on the Active Directory server. (I know… ) The MS ADCS become available, so I could create a new certificate again.

Go back to the SSL Certificate Automation Tool and did the same steps as above. The results:

[.] 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..."
"Starting vCenter Server and other services..."

[2016.08.26. - 15:49:07,19]: Last operation update vCenter Server SSL certificate completed successfully.
[2016.08.26. - 15:49:07,20]: Go to the next step in the plan that was received from Update Steps Planner.



Also tried with the PowerCLI:


The new certificate is valid till 26th of August, 2018. Of course the inventory is visible in the Web Client and I could also login to the vCenter via the vSphere Client. I have corrected the date and time of the AD, AD CS and vCenter servers – everything back to normal.

In the last post (part 3 of 3) the 3rd party components will be fixed.

This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.