Technical Tip: Why self-signed certificates are not supported when using LDAPS and how to generate a correct certificate signed by a CA

Description

This article describes why if the DC is using a self-signed 'cert' the LDAP connection will always fail.

Scope

FortiOS v7.4.4+.

Solution

Starting in FortiOS v7.4.4, LDAPS enforces the trust of the server certificate presented from the LDAP server.

In a normal situation where there is a server with the CA role present in the AD environment, that would be the one to sign the certificates on each Domain Controller. The FortiGate would need that CA 'cert' imported for LDAPS to work. More info can be seen here: Technical Tip: LDAPS/STARTTLS certificate issuer enforcement.

When LDAPS is enabled on a Domain Controller in an AD environment with no CA, the Domain Controller will use it's own certificate.

Technically, any connection presenting a self-signed certificate can never be trusted by another device, as there is no CA for the device to check the certificate against.

Since the FortiGate is enforcing trust for this certificate, it will never work.

To check what certificate is presented by the LDAP server, take a FNBAMD debug while testing the connection, using the following commands:

diagnose debug reset
diagnose debug app fnbamd -1
diagnose debug enable

Here is the following output if the certificate is self-signed and not supported:

'Cert error 18, self-signed certificate.' is seen, which confirms this. 

The following output is seen if the certificate is simply not trusted (no CA 'cert' imported or missing a sub CA cert):

'Cert error 20, unable to get local issuer certificate.' is seen when this is the case, which is not covered inside of this article (find the right CA cert(s) and import it to solve the issue).

To fix the certificate, the CA role is needed on at least one Domain Controller. The following steps would be for an AD environment where there is a single domain controller.

Open 'Server Manager' so it is possible to add a CA role. Select 'Add roles and features':

Make sure 'Active Directory Certificate Services' is selected in 'Server Roles'. The defaults are fine for these purposes:

After, select 'AD CS' and then 'More' in the banner:

Under 'Role Services', ensure 'Certification Authority' is selected:

Navigate through the dialog.
The defaults are fine here, but it may be desirable to change the 'CA Name'.
In this example, 'CA' is used for the name. 

Once complete, search for 'certlm.msc' in the Start Menu and open it. Navigate to Personal -> Certificates.

If the self-signed certificate is present, 'right-click' and delete it. After doing this, 'right-select'  All Tasks -> Request New Certificate.

Navigate through the dialog. When asked to select the Active Directory Enrolment Policy, select 'Domain Controller' and 'Domain Controller Authentication'.

Once complete, the certificates signed by the new CA are now present in the Personal trust store:

Make sure to navigate to 'Trusted Root Certification Authorities', find the CA 'cert' (this will be named after the CA) and export to a file:

This will be imported into the FortiGate as a CA Certificate.
Navigate to System -> Certificates -> Import -> CA Certificate -> File.
After doing this, the LDAP connection should work properly.
The FNBAMD debug will show the certificate passed verification: