Third Party Application Fails Using LDAP over SSL

[Ned Pyle]

First published on TechNet on Sep 16, 2008
Hi, Michael here. The following issue is one that I have seen come up from time to time and can be a challenge for IT administrators who are trying to use the built in Version 2 Domain Controller Authentication template in their environment. The concern may be seen when folks used a version 1 certificate in the past but the newer one (version 2) seems to give some unexpected results.

So what’s the problem? 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 3 ^rd 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 3 ^rd 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.

So, how do you resolve this little quandary?

a.) You could change you application to be in compliance with RFC 3280 (see excerpts from RFC 3280 below)

b.) You could configure the domain controller to use a certificate based on the version 1 Domain Controller template.

c.) In the Domain Controller authentication certificate template, you can change the subject field from “none” to “common”.  You can then issue a new Domain Controller Authentication certificate to the Domain Controller.  In this certificate, the subject field contains the DNS name of the machine and the SAN field is not marked critical on the domain controller authentication certificate. Then delete the old “Domain Controller Authentication” certificate. Finally, reboot the machine.

Why reboot? As a general rule, if a Domain Controller already has a certificate for LDAP over SSL, it will not pick up the new one until the next reboot.

End result: The 3rd party application can successfully connect to this Domain Controller.

So why did this whole problem occur?

This change to have a “blank Subject field and a Critical SAN field” was made to conform to RFC 3280 (Internet X.509 Public Key Infrastructure   April 2002).  Here’s an excerpt from that RFC on why the change was made:

• Subject Common name use is ambiguous.
• Sometimes a DNS name is stored in this RDN, and sometimes other types of names are stored there.
• The Subject Common Name is also limited to 64 characters in CCITT conforming implementations, so it can easily be too short for a full DNS name.
• The Subject Alt Name extension encoding tags fields to identify their use.
• This RFC was published in April 2002, and the V2 DC template change was implemented in Windows 2003.

The bottom line here is that client applications using LDAP over SSL need to be updated to conform to current standards (mentioned in the afore mentioned RFC)

Our development team tells us this: Currently, we do not expect any immediate negative impact to reverting back to the old name representation – as long as all of the full DNS names are shorter than 64 characters, and as long as all of the characters in the full DNS names conform to the IA5 string character set.

There is certainly a potential danger of some applications no longer accepting DNS names in the Subject Common Name, but we have not yet seen that issue. For more detail you can read the RFC for yourself here (insert link on here http://www.ietf.org/rfc/rfc3280.txt ).

RFC 3280        Internet X.509 Public Key Infrastructure

4.2.1.7 Subject Alternative Name

The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI). Other options exist, including completely local definitions.  Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY be represented in the subject field using the domainComponent attribute as described in section 4.1.2.4.

Because the subject alternative name is considered to be definitively    bound to the public key, all parts of the subject alternative name MUST be verified by the CA.

Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present.  If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical.

...
When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034].  Note that while upper and lower case letters are allowed in domain names, no signifigance is attached to the case.  In addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName of " " MUST NOT be used.  Finally, the use of the DNS representation for Internet mail addresses (wpolk.nist.gov instead of wpolk@nist.gov) MUST NOT be used; such identities are to be encoded as rfc822Name.

Note: work is currently underway to specify domain names in international character sets.  Such names will likely not be accommodated by IA5String.  Once this work is complete, this profile will be revisited and the appropriate functionality will be added.

Finally, here are a few additional links which can be helpful in planning and understanding this issue.



How to troubleshoot LDAP over SSL connection problems

http://support.microsoft.com/kb/938703

You may be unable to connect to a Windows Server 2003-based domain controller by using LDAP over an SSL connection

http://support.microsoft.com/kb/932834

Until next time folks, take care out there!

- Michael Hunter