Issues with View Connection Server GoDaddy SSL certificates

[Bspoke]

I have been fighting with making a GoDaddy SSL certificate work all weekend, this is using View 5.1 (Release Candidate).  I seem to be able to get the certificate imported properly into the keystore (have tried pkcs12 and jks) but when I edit the locked.properties it seems to ignore the keystore and new certificate and simply presents the HTTPS site using the self signed certificate created at install.   I tried rekeying the certificate and generating a CSR based on the VMware KB that oulines the process that did not work.  Most recently I am using this site which allows me to just export the pfx file from my working IIS server.

http://www.jasonpearce.com/blog/2012/01/19/exporting-a-godaddy-wildcard-certificate-from-iis-to-vmwa...

This all appears to work (says certificate imported correctly), I created a locked.properties and keystore.jks and rebooted the server.  However when I go to the website I still get the original self signed certificate (with errors).  My locked.properties file reads as follows:

keyfile=keystore.jks

keypass= <password>

storetype=jks

I copied the keystore.jks file and locked.properties to the following path:

C:\Program Files\VMware\VMware View\Server\sslgateway\conf

When I verify the jks file using C:\Users\sysrjo>keytool -list -v -keystore "C:\Program Files\VMware\VMware View\Server\sslgateway\conf\keystore.jks"  The certificate details appear to be contained within.

The only thing I see in the error logs is as follows:

2012-05-07T09:14:10.464-04:00 INFO  (0CF0-0D9C) <Thread-1> [u] The Secure Gateway Server is checking for connection attempts on http://*:80

2012-05-07T09:14:10.714-04:00 WARN  (0CF0-0D9C) <Thread-1> [u] Ignoring invalid storetype: jks

2012-05-07T09:14:10.714-04:00 INFO  (0CF0-0D9C) <Thread-1> [u] The Secure Gateway Server is using SSL certificate store of type KeyVault

2012-05-07T09:14:11.681-04:00 INFO  (0CF0-0D9C) <Thread-1> [u] The Secure Gateway Server is listening on https://*:443

Anyone else have this issue?  I think my cert is actually fine I just cannot get the connection server to look at it.

[Linjo]

Please post beta related question in the beta forums.

// Linjo

[admin]

I'm having this same issue, though with not GoDaddy certs.  Instead of invalid jks, I'm getting invalid pkcs12.

Since it's not beta anymore, can we discuss?

Thanks.

[Bspoke]

If it helps you at all they *completely* changed the certificate process in 5.1 instead of using the java store they are now using Microsoft's cert store.  Make sure you are not following a 4.6 or 5.0 to start, that was my issue.

[DSeaman]

I wrote a blog post about configuring SSL certificates in View 5.1. It's assuming a Microsoft CA, but many of the steps will be the same for GoDaddy. Just import your GoDaddy cert into the Microsoft computer store instead of going through the certificate request process I outlined.

http://derek858.blogspot.com/2012/05/vmware-view-51-installation-part-1-view.html

[admin]

Looks like I was using the old View 5.0 way of doing certs..  went through the 5.1 doc and it works.  Much easier this new way.

I did have an issue though getting it to recognize, you must delete the default View certificate or else it'll keep using it and not your CA cert.

[cruxv]

That's not completely accurate. The View connection server looks for the "Friendly name" property of the certificate in the windows store. If it's listed as "vdm" it will then use that certificate. Right click on the certificate in the windows certificate mmc snap-in and hit properties. Erase the godaddy junk that's in there (or save it off to a text document), and replace it with "vdm". Then go into the default created certificate properties and rename the friendly name to something other than vdm. After all that, restart the view connection server service. You should now see the correct certificate.

[jeffS2]

I followed the instructions straight off the View 5.1 instructions for SSL and connection server. I got a Digicert SSL cert, imported per instructions using the Microsoft MMC, changed the friendly name to kdm and renamed the previous self-signed cert friendly name to blank. Restarted services (and even tried rebooting server) and still doesn't work. If I rename the previous private key friendly name back to kdm, it works again using the self-signed cert. Here's the errors I see in the log when pointing to a Digicert SSL cert.

2012-05-23T18:11:36.540-06:00 WARN  (0D58-1300) <Thread-1> [u] Ignoring invalid storetype: jks
2012-05-23T18:11:36.540-06:00 INFO  (0D58-1300) <Thread-1> [u] The Secure Gateway Server is using SSL certificate store of type KeyVault
2012-05-23T18:11:36.618-06:00 ERROR (0D58-1300) <Thread-1> [KeyVaultKeyStore] No qualifying certificates in keystore
2012-05-23T18:11:36.649-06:00 INFO  (1754-0DAC) <Thread-57> [TransferMessageHandler] attempting to get JMSCluster instance
2012-05-23T18:11:36.727-06:00 ERROR (0D58-1300) <Thread-1> [KeyVaultKeyStore] No qualifying certificates in keystore

012-05-23T18:11:46.556-06:00 WARN  (0D58-1128) <HTTPS Connection Processor> [Processor] Problem with HTTP listener: No available certificate or key corresponds to the SSL cipher suites which are enabled.

Also, the instructions in the 5.1 Admin guide give the steps for the importing the cert into the MMC. Half the steps aren't possible because it doesn't even ask me for the things that the steps are saying should come up. When I import the digicert  pb7 file I got it just shows up in the personal folder, it doesn't ask for password, doesn't give you the option to mark as exportable and there's nothing in the general tab that would come close to saying "you have a private key".  Extremely fustrating. I even deleted and started again, same thing. Steps 1-4 on the actual import work but steps 5-9 below aren't even asked.

5	Type the password for the private key that is included in the certificate file.
6	Select Mark this key as exportable.
7	Select Include all extendable properties.
8	Click Next and click Finish. The new certificate appears in the Certificates (Local Computer) > Personal > Certificates folder.
9	Verify that the new certificate contains a private key. a In the Certificates (Local Computer) > Personal > Certificates folder, double-click the new certificate. b In the General tab of the Certificate Information dialog box, verify that the following statement appears: You have a private key that corresponds to this certificate.

[cruxv]

"vdm" not "kdm"

the friendly name has to be "vdm"

[admin]

That's correct, I could have renamed the default cert friendly name from VDM to something else, instead of deleting.  Both ways seem to work.

Thanks

[jeffS2]

Yeah it was a typo in my message. I am using vdm as well.

[Schraeger]

You need to import the pfx file.

[Michelle_Laveri]

@Derek Seaman...

Can I say thank you very much for writing that blogpost - that REALLY helped...

It is rather annoying that VMware has chosen to change the way cert enrollment is managed mid-way through the lifetime of View 5.x. One can only assume that they were forced to do it some meet some compliance or regulations such as FIPS since 5.0 was released.

The bumps in the roads might have been less had their own documentation been as clear as your blogpost!

Regards

Mike

[Michelle_Laveri]

I've spent the day resolving SSL certificate issues (thanks VMware!)... One interesting anonolmy has presented itself.

Valid Certs on the SS result in the alarm in the dashboard being cleared...

Valid Certs on the CS result in the alarm in the dashboard remaining red...

Despite the fact that the cert was generated in exactly the same way...

My next task is to work out my F5 BIG-IP Appliance stopped working after the upgrade to View 5.1...

I've had smooth upgrades - and do wonder what the wisdom is being changing the comms in this way within a release...

Regards

Mike

[Michelle_Laveri]

Although its not the original subject of this thread. I just wanted to report back my experiences.

I've managed to resolve the "red" alarm on my connection servers. It turns out these need the "External URL" value as the name for the certificate - when they are coupled to the Security Server...

So my public id is something like view.corp.com, but my certs on the connection servers we set to cs01.corp.com and so on...

I removed the old cert that I created and export/imported the view.corp.com cert the alarm was then cleared.

Obivious when you think about it...

Regards

Mike

[Prime_ID]

I would also thanks DSeaman for a great post that saved us with implementing certificates. Thanks!

[DSeaman]

Glad my blog was helpful.