Hello Colleauges
Due to Vulnerability Scann check I get medium scan breaches related to router certificate (JMS) 4001 port
So, do we have some solution to hardening JMS SSL or some risk acceptance of false positive prooved KB about that?
I find VMware Knowledge Base that is described similar false-positive client connection related issue
Maybe someone is resolve problem like that?
Anyway will appreciate for any help
I can't believe!
is nobody used Nessus scan and works without IT security? Or just "open case" without any suggestion?
We would need more info. What is the vulnerability or issues that Nessus is reporting?
Plugin name | Port | Protocol | Service name | Plugin output | Solution | Synopsis | Plugin version ID |
SSL Certificate with Wrong Hostname | 4101 | tcp | unknown | The identities known by Nessus are : "///IP address///" "///Mac address///" "///Hostname///" "///alternative FQDN DNS alias///" "///FQDN name///" The Common Name in the certificate is : router/"///Hostname///" | Purchase or generate a proper certificate for this service. | The SSL certificate for this service is for a different host. | 169372 |
SSL Self-Signed Certificate | 4101 | tcp | unknown | The following certificate was found at the top of the certificate chain sent by the remote host, but is self-signed and was not found in the list of known certificate authorities : |-Subject : CN=router/"///Hostname///" | Purchase or generate a proper certificate for this service. | The SSL certificate chain for this service ends in an unrecognized self-signed certificate. | 169402 |
Red - Certificates with too long timespan | 4172 | tcp | unknown | Certificate lifespan is longer than 825 days Mar 24 11:26:22 2019 GMT Mar 22 11:26:22 2024 GMT | Request certificate with shorter lifespan. | 199951 | |
SSL Self-Signed Certificate | 4002 | tcp | pxc-spvr-ft? | The following certificate was found at the top of the certificate chain sent by the remote host, but is self-signed and was not found in the list of known certificate authorities : |-Subject : CN=router/"///Hostname///" | Purchase or generate a proper certificate for this service. | The SSL certificate chain for this service ends in an unrecognized self-signed certificate. | 169402 |
SSL Self-Signed Certificate | 4172 | tcp | unknown | The following certificate was found at the top of the certificate chain sent by the remote host, but is self-signed and was not found in the list of known certificate authorities : |-Subject : C=CA/ST=British Columbia/L=Burnaby/O=Teradici Corporation/OU=SoftPCoIP/1.2.840.113549.1.9.3=SecurityGateway/CN="///FQDN Hostname///" | Purchase or generate a proper certificate for this service. | The SSL certificate chain for this service ends in an unrecognized self-signed certificate. | 169402 |
SSL Certificate Cannot Be Trusted | 4002 | tcp | pxc-spvr-ft? | The following certificate was at the top of the certificate chain sent by the remote host, but it is signed by an unknown certificate authority : |-Subject : CN=router/"///Hostname///" |-Issuer : CN=router/"///Hostname///" | Purchase or generate a proper certificate for this service. | The SSL certificate for this service cannot be trusted. | 185667 |
I would consider those false positives that can be ignored. For all of the communication you listed there are additional safeguard in place.
Port 4172 is for PCoIP. If you must you can replace the PCoIP Secure Gateway (PSG) certificate.
SSL certificate error when scanning PCoIP secure gateway port 4172 (1038762)
Configure the PCoIP Secure Gateway to Use a New TLS Certificate
This section of the documentation covers how Horizon performs other means of validation for the message bus traffic on ports 4001 and 4002.
Certificate Thumbprint Verification and Automatic Certificate Generation
Port 4101 is used for the connection server JMS traffic. Make sure you are in Enabled or Enhanced mode.
Firewall Rules for Horizon Connection Server
Understanding Communications Protocols
Message Security Mode for Horizon 7 Components
Global Security Settings for Client Sessions and Connections
I ran into the same issue with Nessus scans. Found this article for port 4172. https://kb.vmware.com/s/article/58868 Can't find any articles for port 4101 and 4002