Hi there,

I looked into this and I don't understand :( Would you please clarify why a DN such as "/C=CA/O=Grid/CN=host/somehost.somedomain.ca" is broken? You said "somehost.somedomain.ca" is not a valid RDN because it just has a value and not a type, however the RDN is not just "somehost.somedomain.ca" but "CN=host/somehost.somedomain.ca" which has a type of "CN" and a value of "host/somehost.somedomain.ca" does it not? If this RDN is in fact valid, I still don't understand why DNs of the form "/C=CA/O=Grid/CN=host/somehost.somedomain.ca" seem to not work with LDAP.

Thanks,

Stephen

On Wed, Sep 2, 2009 at 7:35 PM, Howard Chu hyc@symas.com wrote:

Stephen Cartwright wrote:

...

Hi there,

Are there any restrictions on the DN or other attributes of credentials used for LDAP authentication?

We are using grid credentials (X509 format) with DNs like this:

issuer= /C=CA/O=Grid/CN=Grid Canada Certificate Authority subject= /C=CA/O=Grid/CN=host/somehost.somedomain.ca

"somehost.somedomain.ca" is not a valid RDN. RDNs require both a type and a value, but here you have only a value. Whatever CA software you're using is broken if it's allowing you to create certificates like this.

...

When I use some grid certs (X509 format)  I see this message in the debug output from slapd:

connection_read(10): unable to get TLS client DN error=49 id=3

When I try to connect, I get this:

ldap_initialize( ldaps://somehost.somedomain.ca ) ldap_bind: Can't contact LDAP server

The openssl command to create a connection works OK:

CONNECTED(00000003)

Certificate chain   0 s:/C=CA/O=Grid/CN=host/somehost.somedomain.ca     i:/C=CA/O=Grid/CN=Grid Canada Certificate Authority   1 s:/C=CA/O=Grid/CN=Grid Canada Certificate Authority     i:/C=CA/O=Grid/CN=Grid Canada Certificate Authority

---

Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/C=CA/O=Grid/CN=host/somehost.somedomain.ca issuer=/C=CA/O=Grid/CN=Grid Canada Certificate Authority

---

No client certificate CA names sent

SSL handshake has read 2083 bytes and written 320 bytes

New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 1024 bit SSL-Session:      Protocol  : TLSv1      Cipher    : DES-CBC3-SHA      Session-ID: 43B46528E848663E7C8E9CAAEA4E6DB5E4A9675C05C3066DBD826CD1CF59A566      Session-ID-ctx:    Master-Key:

A8245A0731BA98F0D88821346432868C392FEE3F23EAFB9F356A34CB6BB663FC0892374118F280D6284C8E2ACAC3      Key-Arg   : None      Start Time: 1251330160      Timeout   : 300 (sec)      Verify return code: 0 (ok)

When I use certs created by us with another DN format such as this:

subject= /C=CA/ST=Province/L=Town/O=Organization/OU=Unit/CN=somehost.somedomain.ca/emailAddress=email@somewhere.ca issuer= /C=CA/ST=Province/O=Organization/OU=Town/CN=Our CA/emailAddress=email@somewhere.ca

And then make no other changes to the config other than pointing everything to the new commands I can make a connection.

Any suggestions? Please advise.

Steve

--  -- Howard Chu  CTO, Symas Corp.           http://www.symas.com  Director, Highland Sun     http://highlandsun.com/hyc/  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Howard Chu wrote:

Stephen Cartwright wrote:

...

I looked into this and I don't understand :( Would you please clarify why a DN such as "/C=CA/O=Grid/CN=host/somehost.somedomain.ca" is broken? You said "somehost.somedomain.ca" is not a valid RDN because it just has a value and not a type, however the RDN is not just "somehost.somedomain.ca" but "CN=host/somehost.somedomain.ca" which has a type of "CN" and a value of "host/somehost.somedomain.ca" does it not?

That wasn't clear to me from the output you posted before. Since you were posting a DN that uses '/' as its RDN separator, the software that generated this log output should have escaped the '/' in the attribute value if that was really the situation. E.g., it should have looked like /CN=host%2Fsomehost.somedomain.ca.

Using top-down-order and / as separator is the standard behaviour of OpenSSL. :-/ One can also display subject and issuer names in certs with

openssl x509 -nameopt rfc2253

...

If this RDN is in fact valid, I still don't understand why DNs of the form "/C=CA/O=Grid/CN=host/somehost.somedomain.ca" seem to not work with LDAP.

At this point I have no idea what you're really working with. The comment I posted originally may not apply to this situation at all.

Since this is about GRID services I guess someone falsely put a Kerberos service prinicipal name in the CN attribute of the server cert. The cert has to be corrected to contain exactly the FQDN of the server used during LDAP connect *without* the prefix "host/".

Ciao, Michael.

Howard Chu wrote:

Michael Ströder wrote:

...

Howard Chu wrote:

...

Stephen Cartwright wrote:

...

I looked into this and I don't understand :( Would you please clarify why a DN such as "/C=CA/O=Grid/CN=host/somehost.somedomain.ca" is broken? You said "somehost.somedomain.ca" is not a valid RDN because it just has a value and not a type, however the RDN is not just "somehost.somedomain.ca" but "CN=host/somehost.somedomain.ca" which has a type of "CN" and a value of "host/somehost.somedomain.ca" does it not?

That wasn't clear to me from the output you posted before. Since you were posting a DN that uses '/' as its RDN separator, the software that generated this log output should have escaped the '/' in the attribute value if that was really the situation. E.g., it should have looked like /CN=host%2Fsomehost.somedomain.ca.

Using top-down-order and / as separator is the standard behaviour of OpenSSL. :-/

Right, there's nothing wrong with that, it's a well-established practice with a long history. But what's wrong is that when you use '/' as a separator, then you must escape it when it appears in a value.

Yes, but OpenSSL does not do this since the very beginning. Also I don't know a formal specification of this /-based string representation. So probably no-one cares.

Ciao, Michael.