VMware Horizon Community
gmtx
Hot Shot
Hot Shot
Jump to solution

PCoIP Gateway port 4172 certificate/protocol issues

Just got my quarterly security scans back, and while I thought I had my Security Server configured correctly, apparently I still have issues with the PCoIP port/cert.

The scans show the PCoIP gateway on 4172 responding to SSLv3 and not providing a valid cert. I've double and triple checked the registry settings and locked.properties files to be sure I'm not serving SSLv3 and presenting a valid cert, and all those settings look correct.Checking ports 443 or 8443 shows that the protocols/cert are working properly, but the same scan on 4172 shows it responding to SSLV3 and issuing a self-signed (default) PCoIP cert.

Here's what my locked.properties file looks like in C:\Program Files\VMware\VMware View\Server\sslgateway\conf:


secureProtocols.1=TLSv1.2

secureProtocols.2=TLSv1.1

secureProtocols.3=TLSv1

preferredSecureProtocol=TLSv1.2

enabledCipherSuite.1=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

enabledCipherSuite.2=TLS_DHE_DSS_WITH_AES_128_CBC_SHA

enabledCipherSuite.3=TLS_RSA_WITH_AES_128_CBC_SHA

enabledCipherSuite.4=TLS_RSA_WITH_AES_256_CBC_SHA

enabledCipherSuite.5=TLS_DHE_DSS_WITH_AES_256_CBC_SHA

enabledCipherSuite.6=SSL_RSA_WITH_RC4_128_MD5

enabledCipherSuite.7=SSL_RSA_WITH_RC4_128_SHA

enabledCipherSuite.8=SSL_RSA_WITH_3DES_EDE_CBC_SHA

enabledCipherSuite.9=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

And here are the registry settings that the PCoIP gateway should be using for the cert (The SSLCertPSGNI key is properly set to the public fqdn of the Security Server):

pastedImage_8.png

The friendly name on the cert in the Windows cert store is vdm, and there is a private key associated with the cert. As I mentioned, it's only failing on 4172 - 443 and 8443 are working as expected. Any clue where to start looking for why the PCoIP gateway isn't respecting these settings on 4172?

Thanks,

Geoff

Reply
0 Kudos
1 Solution

Accepted Solutions
gmtx
Hot Shot
Hot Shot
Jump to solution

Just got off the phone with support. TL;DR version: It's working.


More detailed explanation, in case you need to please auditors:


Apparently many of the scanning services (in this case, Qualys), fail to do one very important thing when they probe port 4172, and that's send an SNI. Without that crucial bit of info the Security Server will return the default (self-signed) cert, not the one you want. To see this in action, openssl is your friend:


c:\OpenSSL-Win32\bin>openssl s_client -connect "vcs.XXXXXXX.com:4172" -showcerts

Loading 'screen' into random state - done

CONNECTED(000001CC)

depth=1 O = PCoIP Root, CN = PCoIP Root CA

verify error:num=19:self signed certificate in certificate chain

verify return:0

---

Certificate chain

0 s:/O=PCoIP Device/CN=1.1.1.1

   i:/O=PCoIP Root/CN=PCoIP Root CA

...

Now try the same connection sending an SNI (the -servername argument):


c:\OpenSSL-Win32\bin>openssl s_client -servername vcs.XXXXXXXX.com -connect "vcs.XXXXXXX.com:4172" -showcerts

Loading 'screen' into random state - done

CONNECTED(000001CC)

...

Certificate chain

0 s:/C=US/ST=Texas/L=Houston/O=XXXXXXXX/CN=*.XXXXXXX.com

   i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA


The PCoIP gateway is sending the right cert when you connect with the View Client or with a browser, but if another program (like openssl) connects without sending an SNI, you will get the default cert (or nothing at all if disable legacy certs with the reg key).


Hope this helps others who have to explain why 4172 shows up as vulnerable on audit reports.


Geoff

View solution in original post

4 Replies
gmtx
Hot Shot
Hot Shot
Jump to solution

I think I'll open a ticket on this one and see what support says.

BTW, if anyone is following this be really careful about that SSLCertPresentLegacyCert reg entry. I had put that in there to see if I could force the gateway to use the signed cert, and forgot to take it out. Didn't take long for some of my users with older versions of the View client installed to let me know I had broken the gateway.

Reply
0 Kudos
gmtx
Hot Shot
Hot Shot
Jump to solution

Just got off the phone with support. TL;DR version: It's working.


More detailed explanation, in case you need to please auditors:


Apparently many of the scanning services (in this case, Qualys), fail to do one very important thing when they probe port 4172, and that's send an SNI. Without that crucial bit of info the Security Server will return the default (self-signed) cert, not the one you want. To see this in action, openssl is your friend:


c:\OpenSSL-Win32\bin>openssl s_client -connect "vcs.XXXXXXX.com:4172" -showcerts

Loading 'screen' into random state - done

CONNECTED(000001CC)

depth=1 O = PCoIP Root, CN = PCoIP Root CA

verify error:num=19:self signed certificate in certificate chain

verify return:0

---

Certificate chain

0 s:/O=PCoIP Device/CN=1.1.1.1

   i:/O=PCoIP Root/CN=PCoIP Root CA

...

Now try the same connection sending an SNI (the -servername argument):


c:\OpenSSL-Win32\bin>openssl s_client -servername vcs.XXXXXXXX.com -connect "vcs.XXXXXXX.com:4172" -showcerts

Loading 'screen' into random state - done

CONNECTED(000001CC)

...

Certificate chain

0 s:/C=US/ST=Texas/L=Houston/O=XXXXXXXX/CN=*.XXXXXXX.com

   i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA


The PCoIP gateway is sending the right cert when you connect with the View Client or with a browser, but if another program (like openssl) connects without sending an SNI, you will get the default cert (or nothing at all if disable legacy certs with the reg key).


Hope this helps others who have to explain why 4172 shows up as vulnerable on audit reports.


Geoff

eturek
Contributor
Contributor
Jump to solution

I have been going through the same thing (with Trustwave) and also found the official kb from vmware that I referenced when filing my dispute...

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=209945...

Reply
0 Kudos
JonnyHavoc
Contributor
Contributor
Jump to solution

So I was doing some research on this and I come upon the following link which says you can change the self-signed with a CA signed one if you have PCoIP Management Console 2.x or 3.x - Teradici Technical Support

Then I came upon this link Teradici PCoIP® Management Console which tells you how you how to upload your own cert. So this is is a half answer half question. The question is: Is the Self-Signed certificate that is used by the Management console the same one that is used by the gateway? If so, is this fix working?

Reply
0 Kudos