[Date Prev][Date Next] [Chronological] [Thread] [Top]

syncrepl, client certificate containing subjectAltName and non UTF-8 chars


I'm trying to get multiple syncrepl-powered replicas available under the
same DNS name. I use OpenLDAP-2.3.32

Each replica has a certificate with 
Clients can hapily conntect to it, that part works.

syncrepl is working with the provider using a certificate, but now I'd 
like the consumers to use certificate too, so that the provider does not push
sensitive data to anyone that pretend being a replica. 

After two days of fight against the machine, I discovered that I could not
use a different certificate for the syncrepl consumer and the LDAP service
running on the replica. This is a bug in 2.3.x, as explained by Howard Chu:

So I have to use the same certificate. I could live with that, but it does
not work: I add this to the syncrepl statement on the consumers' slapd.conf

And when restarting it, I get this error:
do_syncrep1: rid 217 ldap_sasl_interactive_bind_s failed (7) 

I tried to use my certificate with ldapsearch. With an appropriate .ldaprc,
I can try this (the server here is the provider):

# ldapsearch -b "" -s base +                                       
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
        additional info: SASL(-4): no mechanism available: 

Using a certificate that does not have subjectAltName, it works fine, so 
the provider is not rejecting me.

Here are my certificates Subjects, the one without subjectAltName that works,
and the other one that breaks (obtained by openssl x509 -text, a bit 
modified, but you have the point: yes there are ISO-8859-1 chars in O)

C=FR, ST=France, O=Exemple d'organisation accentuée, OU=foobarbuz, 
C=FR, ST=France, O=Exemple d'organisation accentuée, 

Playing with gdb shows that the server rejects the certificate in 
libraries/libldap_r/utf-8.c:ldap_ucs_to_utf8s(), returning LDAP_INVALID_SYNTAX 

I searched the web, and it seems that ISO-8859-1 chars in certificate
subjects are not a good idea. Changing that means also changing the 
certificate authority, that's something I'd like to avoid. Do I have 
another solution?

That kind of problem has been discussed already on the mailing list. It
seems Howard Chu added ldap_ucs_to_utf8s() to address non UTF-8
chars in certificates subjects:

ldap_ucs_to_utf8s() contains really black magic, it would require one
more day for me to understand what happens there. Is it possible that
it is smart enough to workaround non UTF-8 chars in the general case, 
but fails when subjectAltName is used? 

Please help! How can I get this mess working?

Emmanuel Dreyfus