VMware View certificate revocation issues, who's the man in the middle


Who’s the man in the middle?

Certificates are a challenge in many environments, when not implemented correctly they can bring misery to expected functionality. This short blog will talk about an issue I had with certificates in a VMware View 5.2 environment.

Introduction

Before I begin about the issues we ran into I first will give a short introduction of the environment, this will get us on the same train.
The environment, as said before, is a VMware View 5.2 Windows 7 desktop implementation. The Certificate Authority (CA) is an internal one, installed on the first domain controller ( Let’s call it DC1).

For the VMware view controllers a copy of the default web server certificate was created and deployed. The CA was installed with the extension to support ldap and http revocation checking. The newly certificate was named VMware View SSL and deployed to the connection servers.

The clients in the environment were mainly non-domain members, the clients are HP Thin clients, running Windows 7 embedded. To enable revocation checking for these clients the http extension was enabled. The Thin clients have the root certificate installed in the trust store so the chain is trusted.

The happening

Now after a lengthy introduction let’s get to the issue I experienced.
The Thin clients, that are no members of the domain, will give an error message when they try to connect to the VMware View VDI desktop and when they log off.

The error they give is that they can’t verify if the root certificate for the domain is still valid.

This seemed odd for the VMware View client still shows the connection is secure.

The issue seems to be around the chain of certificate where the chain can’t be verified.

To further complicate the matter I should tell you that the VMware view SSL certificate has three CN’s assigned (common name). The names assigned are Desktop, Desktop.doamin.local, Viewserver.domain.local.

The clients connect to Desktop.domain.local which is provided with DNSRR.
The whole data center is hosted externally so the user is travelling over partly managed lines.

Debugging
After a few days I got fed up with the issue and decided to call in a AD specialist and together we looked closer at the issue.
We opened up one of the Thin clients and run the support.bat 2 command from the DCT directory. This will create a huge batch of log files and information.
When looking at the User debug log I noticed an entry about a man in the middle attack.

The log states that it was expecting a certain certificate with a certain thumbnail but received something else.
Both thumbnails are reported in the log so it was easy to figure out which certificate was presented..

….at least that’s what you would think…

I installed the CA and deployed all the certificates in use at this moment in that organization. I checked each and every one of them and the thumbprints are not matching, not even close.

We have two Connection servers running, the screenshot below is from the first one.. you see that the thumbprint is different than written in the log.

Below is a screenshot of the second connection server, again the thumbprint is different than mentioned in the log.

..and for the proof, when users connect to Desktop they get a certificate from one of the connection servers.
Mind the little lock on the right top corner, the certificate is recognized as valid.

Suddenly the man in the middle made more sense, but still I don’t understand how this would happen.

After a few Twitter posts I got in contact with Gunnar and the first thing he asked when explaining this was if I had DLP running.

DLP would explain this behavior for it would provide a different certificate to the requester…. The customer however doesn’t have anything like DLP running they claim.

I haven’t installed or worked long enough in that environment to verify this but there is something between the user and the CA that is breaking up the certificates..

Where do we stand?

At this moment we are in the forest looking at all the trees and wondering…all clues on solving it ended up a dead road.

Any thoughts on this are welcome, I’ve never seen anything like this before.
A thought would be to use stuff like Fiddler to perhaps see more of the traffic going on or use a sniffer tool to debug. That will take some time but I guess will be the next step.

Latest development

A few Thin clients have been edited to make sure they only connect to one connection server. After this change, disabling DNSRR, the issue has not arisen. 
Before we bring out the champagne, this is weird because DNSRR is used so many times in similar cases.
Something is biting us and we don’t know what it is…
The story will continue.

Leave a Reply

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