Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Deprecated Key Length discovered on PCoIP certificate detected by a PCI scanner on View Security Server. (58868)

Last Updated: 10/20/2022Categories: InformationalTotal Views: 5600Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

A Scanning vendor that performs PCI scans has detected a certificate on our View Security Server that is using a deprecated Key Length.

The certificate has been detected on port 4172 and also appears to mention PCoIP.

The scans show the PCoIP gateway on 4172 responding to SSLv3 and not providing a valid cert. The certificate affected is called PCoIP certificate 1.1.1.1.

Cause

The PCI scan done by vendors fails to do one very important thing when they probe port 4172, and that is to send an SNI.

Without SNI information, Security Server will return the default (self-signed) cert, not the one that is actually in use or the one that has been updated.

Below is the difference we get without SNI (the -servername argument) and with SNI

Here is the command without SNI that the PCI scan runs and marks it as vulnerable :

C:\Software\OpenSSL\bin>openssl.exe s_client -connect " vcs.XXXXXXX.com:4172" -showcerts

CONNECTED(00000104)
depth=1 O = PCoIP Root, CN = PCoIP Root CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/O=PCoIP Device/CN=1.1.1.1
i:/O=PCoIP Root/CN=PCoIP Root CA
-----BEGIN CERTIFICATE-----
MIIDEDCCAfigAwIBAgIJAMW4gkQr3114MA0GCSqGSIb3DQEBBQUAMC0xEzARBgNV
…
-----END CERTIFICATE-----
1 s:/O=PCoIP Root/CN=PCoIP Root CA
i:/O=PCoIP Root/CN=PCoIP Root CA
-----BEGIN CERTIFICATE-----
MIIDbTCCAlWgAwIBAgIJALahGtZIKOt0MA0GCSqGSIb3DQEBBQUAMC0xEzARBgNV
…
-----END CERTIFICATE-----
---
Server certificate
subject=/O=PCoIP Device/CN=1.1.1.1
issuer=/O=PCoIP Root/CN=PCoIP Root CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2203 bytes and written 434 bytes
---
---

Now when we run the same connection sending an SNI (the -servername argument), we do not see the weak certificate anymore.

Command : openssl s_client -servername vcs.XXXXXXXX.com -connect "vcs.XXXXXXX.com:4172" -showcerts

CONNECTED(000000F8)
depth=0 CN = vconn.intra.local, CN = vconn
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = vconn.intra.local, CN = vconn
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=vconn.intra.local/CN=vconn
i:/DC=local/DC=intra/CN=intra-AD01-CA
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgITZAAAAARdONDkTHfhogAAAAAABDANBgkqhkiG9w0BAQsF
…
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=vconn.intra.local/CN=vconn
issuer=/DC=local/DC=intra/CN=intra-AD01-CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2046 bytes and written 455 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: E9993E050E8431ABDF9F0975A71B77FFEC4D74A2F27E718595B13CD05A99F863

Session-ID-ctx:
Master-Key: 727228019CBA0D161B02A57597ED7D8B7BC881436B686231734CF9CEEB666789
5A13F3A32B859F512735BD4A60B4B779
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 2d 11 9e e6 cf 8f 9f 2f-a3 b4 6d 39 66 fd 80 56   -....../..m9f..V
…
Start Time: 1537548696
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

In Summary:
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 disabling legacy certs with the reg key).

Resolution

This vulnerability can be ignored safely as here the scan is not running with the SNI

Workaround

Workaround :  The PSG might present the default legacy certificate instead of the CA-signed certificate to a security scanner, invalidating the compliance test on the PSG port. To resolve this issue, you can configure the PSG not to present the default legacy certificate to any device that attempts to connect.

Start the Windows Registry Editor on the View Connection Server or security server computer where the PCoIP Secure Gateway is running.

Navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Teradici\SecurityGateway registry key.

Add a new String (REG_SZ) value, SSLCertPresentLegacyCertificate, to this registry key.

Set the SSLCertPresentLegacyCertificate value to 0.

Restart the VMware Horizon View PCoIP Secure Gateway service to make your changes take effect.

That will return the result  below for the PCI scan without SNI :

​
CONNECTED(000000E8)
8728:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177
:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher    : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1537550668
Timeout   : 300 (sec)
Verify return code: 0 (ok)

Related Information

Security Server:

A security server is no longer an option with Horizon 8. We have replaced this functionality with a secure Linux appliance -   VMware Unified Access Gateway

Horizon 7 supports the usage of UAG. it is independent and more secure. You can plan this switch as a discrete task in advance to minimize the complexity and mitigate risk.

We have a step-by-step Video KB on how to deploy it. Unified Access Gateway (UAG) deployment and configuration for Horizon (78420)

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware Horizon

Related Versions:

VMware Horizon 7.x

VMware Horizon 7

VMware Horizon 6

Take Our Survey

Support Assistant