Third Party Application fails using LDAP over SSL

Well, if you have a third party application which uses LDAP over SSL to connect to the domain controller it may not work initially using the new version 2 Domain controller Authentication certificate. So let’s go over the issue in detail. A 3rd party application was making LDAP over SSL connections to the Domain Controllers […]

Well, if you have a third party application which uses LDAP over SSL to connect to the domain controller it may not work initially using the new version 2 Domain controller Authentication certificate.

So let’s go over the issue in detail. A 3rd party application was making LDAP over SSL connections to the Domain Controllers as part of what it does intentionally.  This was working when the domain controller had a certificate based on the “old style” version 1 Domain Controller template. An Enterprise Certification Authority had issued the certificate. However, the “Domain Controller” certificates have been superseded by certificates based on the “Domain Controller Authentication” certificates which can happen for several reasons that we won’t go into great detail on in this blog post today.  The end result which is seen is that the 3rd party application now fails. 

What is the apparent problem? By default, the “Domain Controller Authentication” certificate has a blank subject field and the Subject Alternate Name (SAN) field is marked critical on the “Domain Controller Authentication” certificate. Simply put, some applications cannot use a certificate if the SAN field being marked critical.

Why is this field important? Some applications may have difficulty using the certificate if the SAN field is marked critical and the subject field is blank because of how these fields are checked when deciding whether to use a certificate.

Full Article

Here’re few additional links which can be helpful in planning and understanding this issue.