On 8/3/10 2:10 PM, Bryan Boone wrote: > Hi everyone. Sorry for the long email, I am kinda a noob to SSL certs. > > I am trying to develop a client application that will use SSL to encrypt LDAP > traffic so that a customer can use his/her LDAP server as a means of logging > into my client application. This client application will reside on a machine > that does NOT have any CA trusted 3rd party certs (i.e. verisign). Also > companies that use this client application will use self-signed certs allot. > [...] > This brings me to my questions. > > First. I really don't know what a cert chain is, or what a cert chain > accomplishes. Second, I assume that a company could setup their LDAP servers > to > have many certs in the cert chain. Since this is the case how do I know > which > is the right cert to grab and store on my client? Third, what is the best > way > to grab the right certs from the LDAP server? > > thanks Well, a cert chain is a series of cryptographic statements that a given trusted third-party (which you do not have) has stated that the chain is trustworthy.
Since you don't have any trust to play with, the idea of a certificate chain is inappropriate to your circumstance. What you are looking for is a certificate that has CA:false in its basicConstraints extension. Unfortunately, in my experience, this can come anywhere in the list of certificates that the client provides. (OpenSSL also has a bug where it doesn't adhere to the prohibition that ONLY those certs needed to build a single chain terminating at a single trust anchor can appear in the chain.) Another way to do this is to find the subjectKeyIdentifier that is not used as an issuerKeyIdentifier in the chain, and that has a CA:false. According to the X.509 specification (which I really wish more people would read, since the 08/2005 version is freely available from http://itu.int/), a CA is not an end-entity, and an end-entity is not a CA. Thus my recommendation to search for a certificate that has CA:false in basicConstraints. And as for searching the LDAP server -- all of the specifications for the data you'll get back (which object classes to search for, as well as their ASN.1) are in X.509 08/2005. The best way to query the LDAP server is to use what you know about the identity in use to get more attributes associated with the identity in use, including certificates issued thereto and used thereby. Instead of relying on "trust anchors" (i.e., cryptographic keys which have been granted some amount of trust to know how to identify someone), you're building your trust chain based on the LDAP server's authority. That's probably a better way than relying on built-in trust anchors, but it would take a greater man than me to figure out all of the potential problem points, such as "false certificates and keys loaded into LDAP". Hopefully, your LDAP administration team is more clued in on security threats to it than I am. -Kyle H
smime.p7s
Description: S/MIME Cryptographic Signature
