On Sun, Feb 10, 2008 at 01:19:49AM -0800, Howard Chu wrote: >> It's true that the /length/ of a string doesn't include the trailing NUL, >> but it does have to be included in the storage /size/ of a C string, and >> it's debatable which is intended here.
> Since this is an ASN.1 structure, one would ordinarily not expect any NUL > termination in the first place. And since other GnuTLS library functions > are returning the raw data size, excluding any trailing NUL, the behavior > you're seeing here is pretty suspicious. Well, granted; it is consistent in newer versions of GnuTLS, though, despite being inconsistent with older versions and with the other crt APIs. >> Given that one of the errors >> returned by gnutls_x509_crt_get_subject_alt_name() is >> GNUTLS_E_SHORT_MEMORY_BUFFER, it seems obvious to me that this should use >> semantics for storage size rather than string length, and the only question >> in my mind is whether the trailing NUL is included as part of the internal >> representation of the string. >> If this is a behavior change as you say, then I guess we need clarification >> from GnuTLS upstream about whether this is intentional. > That sounds like the best step for now. Just to be sure, how was the > certificate created? Using the openssl commandline tool, and specifying a subjectAltName=DNS:hostname entry in the [ v3_ca ] section of /etc/ssl/openssl.cnf. This was created strictly as a test certificate, in response to reports of problems precisely with subjectAltName validation (http://bugs.debian.org/462588#98). > Have you verified that libldap with OpenSSL accepts the certificate > correctly? Yes, I've tested with ldapsearch from OpenLDAP 2.3.30 linked against OpenSSL, which was able to validate the subjectAltName just fine. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED]
