VMware View certificates and thumbprints – Man in the middle issue


VMware View certificates and thumbprints

In one of my previous blog-posts I discussed an issue we experienced on a network with VMware View 5.2 and DNS Round Robin. For you that didn’t read that blog-post, here’s the link http://www.robbeekmans.net/uncategorized/vmware-view-certificate-revocation/  
This blog will guide you to the resolution to fix that issue. There are more ways to achieve this but this one of them.  

Wake Up call

Well let me start by saying that  I’ve been a complete idiot… the error message as you might recall was that the thumbprint was not as expected, the error stated that it could be because of a man in the middle attack.
I thought about it for a long time, talked to several people about it and we never came to the conclusion that the difference in thumbprint on both servers was the reason for this error.
When you read the VMware installation guides the point you to the certificate MMC to request a CA created certificate. This is fine when you use a load balancer but not OK when you use DNS Round Robin. With DNSRR the client might start talking to one server and later on during the day get in contact with the other one. The client doesn’t know that they are different server and therefore tells you that he got a different thumbprint, one that wasn’t expected. It was there under my eyes the whole time and I didn’t see it… Credits for helping me see the light go to @DSRademakers, we shared thoughts and this is what you should do to fix the issue. There is an article from VMware about this, it’s http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2032400. This blog will show you the graphics and some more details not mentioned there, like how to get the alternative names accepted.

Requirements

The requirements are basic things like a internal CA and a few connection server.
You will need to fix the CA to accept Alternative names (SAN).
So before you can do anything with the certificates, go to the internal CA and start a command box as administrator.
Run these commands to add support to the internal CA for Alternative names, it will do a restart after you finish. Perhaps it’s better to do this in off-office hours.
Add two A-Record host names to DNS and point them to both connection servers.

Create certificate

All the way at the bottom is the text version of the Request.inf file needed to create a certificate request.
Fill in the subject part, where you would add the A-Record address you added in DNS.
At the bottom of the file you seen the SAN names, add as many as you want and make sure you use a & between them. In my lab I also added the DNS name Desktop.2012dc.local as a SAN name.
Next step is to generate the certificate request, Run Certreq – new request.inf certreq.txt to generate the text file. The text file is a bug bag of characters, all you have to do is copy everything in the file and keep it ready for the next step.
Open a web browser and browse to your internal CA, my address is HTTP://Win2012.212dc.local/certsrv
Click on Request a Certifcate
Click on Advanced certificate request
Click on Submit a certificate request by using a base-64…….
Paste the contents of the certreq.txt file in the box and select Web server as a certificate template. Click Submit.
Choose Base 64 encoded and click on Download certificate
Save the certificate in the same folder to make things easier, give it a name you find easy to remember.

Next job is to add the certificate to the certificate store.
The command for this is Certreq -accept certnew.cer, where certnew.cer is the name I chose for the certificate.

The certificate is added to the store, as you can see in the picture above.

VMware View requires a restart to make use of the new certificate. make sure you have only one certificate with the friendly name vdm otherwise it will not work as expected.
When we open the certificate it shows the SAN names.
It also shows the Thumbprint, remember this one, it starts with a1 and ends with 23.
Now we have one server ready, but we have two. 
We need to export the certificate to use it again on the other server, so here we go
Right click on the certificate and go to Taks/Export.
(I’ve only added the screen that need attention, next and finish you’ll find yourself)
Click on Export the private key
Click on Include all certificates in the certification path if possible
Type in a password you will use to import it later on
Save it and name it so that you can use it later on to import it.
Now we go to the second connection server and do an import.
Open the Certificate MMC /Computer/local computer and right click on personal. Go to  All Tasks/Import.
(I’ve only added the screen that need attention, next and finish you’ll find yourself)
Browse to the file you have saved earlier on (guess you copied it over to the second server)
Type in the password you set earlier.
Let the wizard do it’s job, he knows where the cert came from.
Restart the services and you’re good to go.

I hope you remembered the thumbprint, because here it is, starting with a1 and ending with 23. they are the same.

All is green

One small final test was to connect to all possible addresses and see if it was accepted, as you can see all is green which is good. 

when we look at the dashboard, all is green there, so the certificates have been accepted.

Conclusion 

Sometimes it takes a while to see what is there all along, thanks to a good conversation on a rainy evening over Teamviewer we saw the light. The tests have been going for over a day now and the error hasn’t pop-up so far.. we keep our fingers crossed but this really should be it.
After this was fixed I was wondering why it went wrong, we use DNSRR more often in these solutions. Our customers are reluctant to buy stuff when a free alternative is available.
I went to a customer where they had 5.1 running. 5.1 also uses certificates, this customer also uses DNSRR.
The certificates on both servers are different, they are enrolled from the internal CA with the MMC, so two different thumbprints.
I checked and asked them if they experienced the issue but they haven’t. Next week I’m going back there and will do a follow-up check to make 100% sure I’m looking at the right stuff. It seems however that something is different in the way 5.1 and 5.2 handled certificates. Any thoughts on that would be welcome 🙂

Appendix

File

;—————– request.inf —————–
[Version]
Signature=”$Windows NT$”
[NewRequest]
Subject = “CN=Desktop.2012dc.local, OU=Computers, O=2012, L=Beek en Donk, S=NBr, C=NL” ; replace attribues in this line using example below
KeySpec = 1
KeyLength = 2048
; Can be 2048, 4096, 8192, or 16384.
; Larger key sizes are more secure, but have
; a greater impact on performance.
Exportable = TRUE
FriendlyName = “vdm”
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication
[RequestAttributes]
SAN=”dns=desktop.2012dc.local&dns=w2k8r2conn.2012dc.local&dns=w2k8r2conntwee.2012dc.local”

Leave a Reply

https://tracking.cirrusinsight.com/869c29e2-3a9b-48c5-9232-0b95e7993ae8/controlup-com-pixel-php