Technical Tip: LDAPS/STARTTLS certificate issuer enforcement

[heljag]

Description	This article describes the changes in the LDAPS/STARTTLS configuration starting from v7.4.4.
Scope	FortiGate v7.4.4.
Solution	Starting from v7.4.4, the LDAPS/STARTTLS server certificate issuer has been enforced. This means that the server certificate issuer (the root CA) needs to be installed on the FortiGate store, as it will otherwise throw an error on the authentication. fnbamd debug: [433] start_remote_auth-Total 1 server(s) to try [1881] handle_req-r=4 [1378] __ldap_tcps_connect-Start ldap conn timer. [1666] __verify_cb-Cert error 20, unable to get local issuer certificate. Depth 0. Subject '/CN=ion-kvm88.labtest.local' [1345] __ldap_tcps_connect-tcps_connect(10.192.11.88) failed: ssl_connect() failed: 167772294 (error:0A000086:SSL routines::certificate verify failed). [1642] __ldap_error-Ret 5, st = 0. [1679] __ldap_error- [1485] __ldap_tcps_close-closed. [1567] __ldap_conn_stop-Stop ldap conn timer. The 'certificate verify failed' error appears when the root CA is not installed on the FortiGate store. To prevent this error, import the certificate (root CA) that signed the server certificate into the FortiGate store. fnbadm debug: [433] start_remote_auth-Total 1 server(s) to try [1881] handle_req-r=4 [1378] __ldap_tcps_connect-Start ldap conn timer. [1669] __verify_cb-Cert preverify ok. Depth 1. Subject '/DC=local/DC=labtest/CN=labtest-ION-KVM88-CA' [1669] __verify_cb-Cert preverify ok. Depth 0. Subject '/CN=ion-kvm88.labtest.local' [1378] __ldap_tcps_connect-Start ldap conn timer. [1363] __ldap_tcps_connect-tcps_connect(10.192.11.88) is established. Current state: Connecting. [1120] __ldap_auth_ctx_reset- [984] __ldap_next_state-State: Connecting -> Admin Binding [1378] __ldap_tcps_connect-Start ldap conn timer. [1221] __ldap_rxtx-fd 10, state 2(Admin Binding) [1223] __ldap_rxtx-Stop ldap conn timer. In this output, after the import, check the server certificate (Depth 0) and the root CA (Depth 1) that signed the server certificate. The error will go and LDAPS/STARTTLS authentications will start to work again. On the LDAP configuration, there is nothing to be changed. When using 'Secure Connection' with 'LDAPS' protocol On several occasions, it is charged a different CA than the one it should import. For example, a CA with a different common name than the one the LDAP Server is sending to FortiGate. The following image shows that the connection was not successful, because the 'CA_Cert_1" has a different common name than it should have. To find out which Root-CA should be imported in this field, it is necessary to perform a PCAP capture with port 636, using the Network, Diagnostic GUI tool. Once obtaining the capture, open it with WireShark, go to the 'TLSv.1.X Server Hello, Certificate, Server key Exchange' package go to the TLS layer, and go to the Certificate/issuer option. In this part, it is possible to validate the Common Name that the server is sending to FortiGate.   Once the CA that the server sends to FortiGate is known, this CA must be searched in the LDAPS server and imported with CA in the FortiGate. After being valid in the FortiGate, it can be used for LDAPS authentication. Note: There are times when, even after updating the server root certificate to the FortiGate certificate store, the authentication will fail due to an 'Unknown CA' error. In one case, the certificate was updated under the Local CA store instead of the Remote CA. After reinstalling the root certificate, when the certificate was under the Remote CA, the authentication was successful. As a result, make sure that the certificate is under the Remote CA in the certificate store. Additionally, ensure that the certificate is correctly downloaded as a CA from the authentication server.