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,