VMware Horizon View Blast Secure Gateway service is Paused

Last week a customer raised a support ticket who had an issue with their Connection Servers. They would end up with the VMware Horizon View Blast Secure Gateway service in a Paused state. This behavior occurred after replacing their current certificate, which was about to expire, for a new one.
Changing back to the original certificate solved the issue and everything would end up in a Running state again.

After getting access to the environment I started checking a couple of things:

• The customer confirmed they used the right procedure when replacing a certificate
• Remove the newly added certificate and added it again
• Compared the old certificate with the new one and found no differences
• Confirmed the private key was exportable, it was

I checked the Blast Secure Gateway logs (absg.log) located in C:\ \ProgramData\VMware\VDM\logs\Blast Secure Gateway\ which showed several lines with the following message:

keystoreutil.exe failed to load certificate from  [ 'windows-local-machine', 'MY', 'vdm' ] 1 Failed to acquire private key handle (error 2148073492)

Checked for any existing VMware KB articles… and bingo! VMware has a KB article online which has the title VMware Horizon View Blast Secure Gateway is in Paused status, so we’re done right?

Following the steps in the article should fill the newly created absg-stderr.log, but that remained empty even after a couple of reboots.
So I did what anyone would do at this point, reverse engineer the solution. Which meant checking if C:\Windows\System32 was available in the PATH environment variable, which unfortunately, it already was.

Due to time constraints, on both my end, the customers and a soon to be expired certificate, we decided to follow up VMware’s advice and contact VMware technical support.

VMware support to the rescue!

VMware technical support came back shortly after opening a support case and recommended to generate a new certificate based on the following KB article (as of October 2020 this link appears to be broken). My colleague Jan Willem followed up on VMware’s advice, as I wasn’t available at that moment.

Generating a new certificate from scratch and replacing the expiring one now worked without any issues. In hindsight It’s hard to tell if something went wrong, or if someone made a mistake during the first attempt, but at least we made the deadline this time.

Just make sure you always start replacing/renewing certificates with plenty of time to spare, as you never know what unexpected issues you might experience!