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):
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
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
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.
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
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...
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?