VULN-003 — SSL Certificate Validation Bypass (LDAP)

Evidence:

// api/Crt.Domain/Services/LdapService.cs, lines 35-44

conn.UserDefinedServerCertValidationDelegate += (sender, certificate, chain, sslPolicyErrors) =>

{

    if (sslPolicyErrors == SslPolicyErrors.None)

        return true;


    if (chain.ChainElements == null)

        return false;

    return true;   // ← accepts ANY cert with a non-empty chain, regardless of errors

};

Description: The certificate validation callback accepts any certificate as long as the chain object is non-null — which is virtually always true. Self-signed, expired, and hostname-mismatched certificates are all accepted.

Impact: Man-in-the-middle attack on the LDAP/StartTLS channel exposing the Active Directory service account credentials (username and password) that are bound in LdapService.LdapSearch.

Recommendation: Replace the delegate with strict validation: return sslPolicyErrors == SslPolicyErrors.None. If the LDAP server uses an internal CA, add that CA to the OS trusted certificate store rather than bypassing validation in code.

Start with api/Crt.Domain/Services/LdapService.cs at lines 35–44 and inspect the certificate validation callback and its handling of sslPolicyErrors and chain. Confirm the intended LDAP certificate-validation behavior, then verify that self-signed, expired, and hostname-mismatched certificates are no longer accepted while valid certificates remain supported.

Written by the indexing model from the issue text.