[Date Prev][Date Next]
Re: (ITS#5938) tls.c does not conform to RFC 4513
--On February 10, 2009 3:56:37 PM +0000 firstname.lastname@example.org wrote:
> Full_Name: nick hudson
> Version: 2.3.38
> OS: linux
> Submission from: (NULL) (188.8.131.52)
> I am looking at the code in tls.c, function ldap_pvt_tls_check_hostname
> (although the code has been refactored in recent versions, into e.g.
> tls_o.c, but the same is true of the new code)
> I think the code is doing something that RFC 4513 says that it should not
> do. Specifically, ref RFC 4513 section 3.1.3 says:
> The server's identity may also be verified by comparing the reference
> identity to the Common Name (CN) [RFC4519] value in the leaf Relative
> Distinguished Name (RDN) of the subjectName field of the server's
> certificate. This comparison is performed using the rules for
> comparison of DNS names in Section 184.108.40.206, below, with the exception
> that no wildcard matching is allowed.
> In tls.c (and the refactored code), you can see it's first attempting an
> exact comparison on subjectAltName, and if that fails it tries a wildcard
> match (which is ok, as per section 220.127.116.11)
> But if no subjectAltName match is found, there's another section which
> looks at the certificate's subjectname, in which it also does a wildcard
> match, although the RFC says this shouldn't be done.
This is because the Cert vendors themselves don't honor the RFC's when
issuing wildcard certs, and was added so that their broken wildcard certs
could still be used.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration