[Date Prev][Date Next]
Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
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
> Have you verified that libldap with OpenSSL accepts the certificate
Yes, I've tested with ldapsearch from OpenLDAP 2.3.30 linked against
OpenSSL, which was able to validate the subjectAltName just fine.
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/