By Jesper Alberts ** Update December 2020 **
The link to the KB article is working again.
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. My former 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!
Certificates are always a joy to work with 😉
They sure are!
Just a heads up, the link seems to go to a kb article that doesn’t exist and when doing a kb search for 2068666 it just says invalid page
Thanks for the heads up! It appears they pulled the article, even though other KB articles still refer to it.
I’ll keep my eyes open and see if I can find an updated article.
Hi Nick, the KB article has been restored!
Hi,
Thanks for your blog post.
It was probably the first certificate that didn’t had the “Make private key exportable” checked.
Glad it was of use to you!
Tristan Kekermans was correct. When I updated the certificate, I didn’t tick that checkbox…results in a “paused” state after I restarted the service.
Taking the hint, I re-imported the same certificate, this time ticked the checkbox, and the service came up!
Glad you’re up and running again!
The VMware documentation on certificate replacement leaves out an important wrinkle. When you create a CSR from a Microsoft Windows server you must select “Legacy key.” The default choice when Windows presents the certificate request dialog box is “CNG key,” which is not compatible with Horizon.
If you attempt to use a CNG key, Horizon will throw the same error in absg.log as it does if your private key is nonexportable (Failed to acquire private key handle error 2148073492). It will also throw that error if the Horizon Blast Secure Gateway does not have permissions to the private key, but that’s a less common failure condition.
Thanks for the post. This helped solve my issue with the service being paused.
hi, this work
Good article. For us the service was paused because our Carbon Black anti-virus blocking the Java Script file that the VMBlastSG service calls. The JS file is located at c:\program files\vmware\vmware view\server\appblastgateway\node_modules\log4js\lib\levels.js. I turned off Carbon Black and the service started right up. I went ahead and googled VMware Horizon anti-virus exceptions and created a new policy in Carbon Black with those exceptions.