If you are in an environment without a PKI (Public Key Infrastructure) without any CA(s), the DC wouldn’t have any ADDS certificates in its Personal Store. LDAPs connections on port 636 would fail via LDP.exe and presumably from the Fortigate.

The March 2020 updates appear to enforce signing and require either SSL on port 636 or SASL logins via 389. If your Fortigates are using "regular" LDAP binds unencrypted on port 389, that will break if signing is enforced.

Applications and other devices relying on unecrypted LDAP binds on port 389 will also be affected. Not all of these may support LDAPS. Some remote SaaS applications doing LDAP binds via VIPs may have varying degrees of LDAPS support as well.

This would lead me to believe the recommendation would be to setup a proper Certificate Authority hierarchy and issue your DCs Certificates. Conversely, installing a third party certificate on the DC and using split DNS so that the name matches may be an option. I have seen recommendations where if you have a .local AD domain you would need to setup a UPN with your public domain name along with split DNS. Remote SaaS services may need a third party certificate installed that has a CN or Subject Alternative Name that matches the destination fqdn of your public domain.

The nuclear option would be to ensure the "ldapserverintegrity" registry key is set to "0" after the update to allow unencrypted 389 LDAP binds to continue to work.