Bug 1740070

Ugh, sorry, I was thinking about another use-case when I created the bug report and wrote EKU with a subjectAltName. Of course subjectAltName is not part of the EKU..

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3674

Both of these patches should be dropped: https://git.centos.org/rpms/openldap/c/2ba5f0fe973f7ab0311beafc90fa2a0f7ffd7f52?branch=c8


The LDAP protocol *specifically* follows RFC4513.

If you read RFC6125 section 1.4, it *specifically* states:

 This document also does not supersede the rules for verifying service
   identity provided in specifications for existing application
   protocols published prior to this document, such as those excerpted
   under Appendix B

and if you go even FURTHER and read appendix B (https://tools.ietf.org/html/rfc6125#appendix-B) section B.3 calls out the LDAP protocol as being an exception.

Or I should say, the "new" patch using OpenSSL should be dropped, and the other one was correctly dropped already.

Thanks for pointing that out. What is the effect that the patches are having? Have problems been reported?

The effect is that RedHat builds of libldap from the OpenLDAP software version 2.4.46-10 and later directly violate the LDAP RFCs and do incorrect cert verification.

CVE-2020-15719 needs to be retracted, the patches dropped, and a new CVE filed for builds 2.4.46-10 and 2.4.46-11 that they violate certificate matching as pertains to the LDAP protocol.

My new patch follows the rules of RFC 6125 appendix B.3 for LDAP protocol, specifically:

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

and

   The server's identity may also be verified by comparing the reference
   identity to the Common Name (CN) [LDAP-SCHEMA] value in the last
   Relative Distinguished Name (RDN) of the subject field of the
   server's certificate (where "last" refers to the DER-encoded order,
   not the order of presentation in a string representation of DER-
   encoded data).  This comparison is performed using the rules for
   comparison of DNS names in Section 3.1.3.1, below, with the exception
   that no wildcard matching is allowed.  Although the use of the Common
   Name value is existing practice, it is deprecated, and Certification
   Authorities are encouraged to provide subjectAltName values instead.
   Note that the TLS implementation may represent DNs in certificates
   according to X.500 or other conventions.  For example, some X.500
   implementations order the RDNs in a DN using a left-to-right (most
   significant to least significant) convention instead of LDAP's right-
   to-left convention.

The RFC has a strong **SHOULD** for SAN dNSName check and a weak **may** for CN. It also lists CN checks as deprecated and encourages the use of SAN dNSName entries.

I'm consider that libldap's default behavior a violates the spirit of RFC 6125. Cedric reported the issue as potential security issue to OpenLDAP a couple of months ago. Howard turned it down. My patch also turns a long C function into a trivial function call and lets OpenSSL deal with gritty details of hostname verification. In doubt there is also the flag X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to restore the (IMHO broken) behavior to always fall back to Subject CN.

(In reply to Quanah Gibson-Mount from comment #23)
> The effect is that RedHat builds of libldap from the OpenLDAP software
> version 2.4.46-10 and later directly violate the LDAP RFCs and do incorrect
> cert verification.

From a practical point of view all public CAs that participate in WebPKI / CAB forum assume that clients follow the baseline requirements for certificates. That means that these CAs and their intermediate CAs always generate end-entity certificates with a proper SAN extension. Our own PKI software like Dogtag PKI and FreeIPA do the same. Legacy certs don't have a SAN extension. OpenSSL's X509_check_host() will automatically fall back to Subject CN check. You are talking about an edge case when a cert has a CN hostname entry and a disjunct set of SAN dNSName entries.

RFC 6125 is at best misguided. SAN is subject*Alternative*Name - it is meant to be used for *aliases*. The canonical name still must be in the cn. The language in 6125 is so jumbled clearly its authors/editors didn't know wtf they're talking about.

DNs are hierarchical names, so talking about left-to-right or right-to-left RDN ordering is just nonsense. RDNs in a DN are sequenced from root to leaf. The only order that matters is their top-down ordering, and the only CN that matters is the one in the leaf RDN.

Perpetuating misunderstanding of DNs, instead of promoting their correct use, serves no one. RFC6125 specifically precludes the use of *aliases* in certs. E.g., with the procedure it prescribes, a cert with SANs mail.openldap.org and www.openldap.org with a CN=openldap.org would be rejected for clients attempting to connect to "openldap.org" because the SANs don't match the request. This is plain nonsense.

OpenLDAP libldap correctly implements the letter and spirit of RFC4513. RFC6125 explicitly states it does not supersede it. 

LDAP spec aside, RFC6125's procedures are clearly broken.

(In reply to Christian Heimes from comment #24)
> My new patch follows the rules of RFC 6125 appendix B.3 for LDAP protocol,
> specifically:

Appendix B.3 simply cut and pastes the relevant text from RFC 2830 and RFC 4513.  Thus it explicitly excludes any changes to be made to LDAP based off of RFC6125.

> I'm consider that libldap's default behavior a violates the spirit of RFC
> 6125. Cedric reported the issue as potential security issue to OpenLDAP a
> couple of months ago. Howard turned it down. My patch also turns a long C
> function into a trivial function call and lets OpenSSL deal with gritty
> details of hostname verification. In doubt there is also the flag
> X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to restore the (IMHO broken) behavior
> to always fall back to Subject CN.

So you're noting explicitly here that your patch changes the behavior of libldap, in violation of RFC4513 and what RFC6125 explicitly sets out.  Nothing here should be honoring the "spirit" of RFC6125 outside of there being no behavior breaking change to RFC4513.  Cedric's issue report was correctly rejected since the proposed changes violate the LDAP RFCs and there is no security issue present.