The X.509 certificate chain for this service is not signed by a recognized certificate authority. If the remote host is a public host in production, this nullifies the use of SSL as anyone could establish a man-in-the-middle attack against the remote host.
Note that this plugin does not check for certificate chains that end in a certificate that is not self-signed, but is signed by an unrecognized certificate authority.
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=Chef Automate 6e0f2607-7ac9-45a9-9c2a-008a794ff08e
For these specific findings there are two service ports that Chef Automate has open which uses X.509 certificates to support encryption between two of their internal only (non-user) services running on ports 10125 and 10143.
From Chef Support:
Chef Automate uses its own self signed certificate on these ports to ensure that the encryption is properly setup out of the box without user intervention, especially since this is only used between internal services of the automate backend.
From Our Security Team:
Security will not accept packages with certs not replaced, period. We will need to maintain pressure on the vendor to allow this to be user replaceable. In addition, since issue was observed by the assessment, the certificate is being presented outside server.