|
Thanks for the most compreensive reply so far Sander. I see, the problem is not easy at all, Now Im curious to know how other people dealed with this problem, if they discovered it at all. if I were not in a country with accented characters probably this would never be a problem to me. I will try to follow the results of this patch you've showed me , hope it works ok, but meanwhile I wlil change strategy (now that I know is not any missing configuration on my system) mod_authz_ldap has another way to validate a certificate. Instead of using the issuer and subject fields I will try to use all the client certificate as the validation field, this way I dont have to deal with utf8 problems, I hope... Luis > From: sctemme@xxxxxxxxxx > Date: Sat, 1 May 2010 09:29:21 -0500 > To: users@xxxxxxxxxxxxxxxx > Subject: Re: UTF-8 strings through ap_log_cerror > > Luis, > > On Apr 30, 2010, at 3:28 PM, Luis Neves wrote: > > > Hi list members, > > > > see here http://marc.info/?l=apache-httpd-dev&m=127242179232546&w=2 > > > > I am the original poster of this issue, unfortunally so far I have no answers to my problem and maybe you can give me some clues > > > > I think this issue is not only related to the logs apache is creating "in ssl_engine_kernel.c" but must be in another place as well, i say this because the mod_authz_ldap is using the incorreclty values (with '\x') to query the ldap directory. > > So IMHO it needs fixing somewere else too..... > > I am not sure, but I think what's going on is that modules/ssl/ssl_engine_vars.c calls X509_NAME_oneline() on line 382 and 388 (in trunk). This populates the "environment" variables that I assume you have configured to pass on to mod_authz_ldap. Per Stephen Henson on the openssl-users list, the right function to use is X509_NAME_print_ex() using (per Kaspar Brand on the dev@httpd list) a memory BIO and XN_FLAG_RFC2253 for formatting. > > Using X509_NAME_print_ex() in these spots would get the DN out of the certificate in a sensible format. The problem is, however, that the ssl_var_lookup_ssl_cert() function returns a char *, not a wchar_t *. So, even if we were to have get the certificate data in the right format, we couldn't pass it up the call stack without escaping it since ssl_var_lookup_ssl_cert(), ssl_var_lookup_ssl(), ssl_var_lookup() and all the functions that call it all expect a char *, and return a char *. This goes up all the way to the ssl_hook_Fixup() function registered as the ap_hook_fixups handler for mod_ssl: this is where the "environment" gets populated with stuff that mod_authz_ldap can use. To fix this issue would mean making this call stack Unicode clean all the way to the top. This of course may cause an avalanche of side effects throughout the code, so before you know it you're rewriting the entire web server. > > So regarding your last comment on the OpenSSL list, it's not that basic. mod_ssl has been part of Apache for ten years or more, and existed as a third party module before that. I would not be surprised if Unicode did not exist when this code was written, so the reason we use a legacy function there is that it is, really, legacy code. > > I doubt you're the first to run into this issue. However, apparently no one confronted with the problem of UTF-8 characters in a client certificate DN has had the time, acumen and energy to solve the problem. > > > I need somebody to confirm this because if it is the case I need to find other way to check the certificates > > If not, so how do I am suposed to use the correct values on the other modules? > > and lastly: should a BUG be filed for this? > > As it happens, there is a partial patch in bug 48780: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 > > However, I don't know if you can stuff Unicode DNs into a char * like Peter is doing. And we'd have to do the same thing for the Issuer field. But if this works, maybe we should entertain it. Luis, would this solve your problem? > > S. > > > Thank you a lot > > Luis > > > > just for context, heres my first post on this problem: > > > > I am trying to match the values coming from apache/mod_ssl/mod_authz_ldap against some fields (subjectDN and issuerDN) in an Openldap directory > > the problem is that Apache is receiving certificate data that contains UTF8 encoded chars > > > > That chars are being incorrectly encoded with '\x' characters (deprecated source code? bug?) and this is making the effect of mod_authz_ldap failing the query with "bad search filter" error > > > > Here some example data on the ssl_error.log > > http://www.mail-archive.com/openssl-users@xxxxxxxxxxx/msg60934.html > > > > I need help on solving this, Iam sucked and dont know what to do to put this thing working > > Can someboby help me please? > > > > PS: Im using Apache 2.2.3 on a Centos 5.4, against openldap > > > > Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now. > > > > -- > Sander Temme > sctemme@xxxxxxxxxx > PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF > > > > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > Hotmail: Trusted email with powerful SPAM protection. Sign up now. |
|