Could the "SSL is available via port 389" be because it is configured to
support the start_tls against port 389?

On 2/20/19 7:00 AM, ab wrote:
> On 02/20/2019 12:14 AM, Eireocean wrote:
>> Morning,
>> We often have Nessus scans performed against our servers and the common
>> vulnerabilities are as follows :
>> - SSL Certificate Signed Using Weak Hashing Algorithm

> This indicates your certificate came from an older version of eDirectory.
> I am going to guess you are on eDirectory 8.8, or maybe even older, or at
> least that you were on that version when certificates were minted. The
> world has changed dramatically in its tolerance of things like SHA1 and
> various ciphersuites, particularly since 2013, and since CAs last for ten
> (10) years by default (if not longer manually) then this is certainly
> possible, even if you happen to upgrade eDirectory today without also
> recreating certs.
>> - SSL Medium Strength Cipher Suites Supported

> This is something you can configure from the LDAP Server (I think, or LDAP
> Group) object linked to this NCP (eDirectory) Server object. You can
> change out to High strength ciphersuites, or disable the TCP 389 port
> entirely, in which case it should not be open at all, so something is
> amiss there for you.
>> - SSL Certificate Cannot Be Trusted

> You can fix this if you want, but it's likely all about being from a
> trusted third-party CA like Digicert, and if that's not the case then
> you'll see this, but that's all it means.
>> - SSL Self-Signed Certificate

> Same as the previous comment, likely.
>> - SSL Null Cipher Suites Supported

> This is very odd; it means you are not setting things as you should,
> locking down ciphersuites on those LDAP objects mentioned above. Do this,
> for sure.
>> - SSL Weak Cipher Suites Supported

> Same as the previous comment, maybe coupled with a need to upgrade to a
> current (9.x) version of eDirectory.
>> - SSL/TLS EXPORT_RSA <= 512-bit Cipher Suites Supported (FREAK)

> Same as the previous comment.
>> Now we are correcting the certificate issue but the main query involves
>> why SSL is available via port 389 and why it is available in general
>> even though it has been disabled. Only feedback I have found is that the
>> scan is a false positive because it is not usable and is there for
>> backward compatibility.

> This should not be the case. There is the option to disable the port
> entirely, and it will not open (for listening) if done, so pursue that.
> Disabling this way has been an option since at least eDirectory 8.7, if
> not 8.6, which was current a couple decades ago.