Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1814674

Summary: if the certificate contains CN=[ip address] the connection to openldap server is rejected
Product: Red Hat Enterprise Linux 8 Reporter: Filip Dvorak <fdvorak>
Component: openldapAssignee: Simon Pichugin <spichugi>
Status: CLOSED ERRATA QA Contact: RHDS QE <ds-qe-bugs>
Severity: low Docs Contact:
Priority: unspecified    
Version: 8.2CC: arajendr, bsmejkal, cheimes, mharmsen, pkis, quanah, sgouvern, spichugi, vashirov
Target Milestone: rcKeywords: Regression, Triaged
Target Release: 8.0Flags: spichugi: needinfo+
pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openldap-2.4.46-18.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-09 19:49:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
configuration file for openldap
none
slapd.conf
none
Certificate with IP address in subject none

Description Filip Dvorak 2020-03-18 14:03:25 UTC 
Created attachment 1671066 [details]
configuration file for openldap

Description of problem:
The TCMS test https://tcms.engineering.redhat.com/case/74568/ started to fail with a new version of openldap (openldap-2.4.46-11.el8). The problem is that it is not possible to create a new ldap-user via luseradd when the ldap-client (ldap.conf,TLS_REQCERT=demand) gets certificate from ldap-server which contains CN=$ip-address.
 
Version-Release number of selected component (if applicable):
- RHEL-8.2.0-20200310.0
- openldap-2.4.46-11.el8
- libuser-0.62-23.el8

Steps to Reproduce:
1. configure openldap server (used configuration files are attached)
2. create a self-signed certificate and copy it into /etc/openldap/cacerts   
openssl req -x509 -new -nodes -out slapd.pem -keyout slapd.pem -days 365  -subj "/C=XX/ST=mystate/L=mytown/O=myorganisation/OU=myou/CN=127.0.0.1/emailAddress=myemail/"
3. luseradd luser1

Note:
The problem can be reproduced by running the mentioned TCMS test in 1minutetip or beaker.

Actual results:
# luseradd luser1
LDAP Bind Password: 
5e722500 slap_listener_activate(7): 
5e722500 >>> slap_listener(ldap:///)
5e722500 connection_get(16): got connid=1000
5e722500 connection_read(16): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 29 contents:
5e722500 op tag 0x77, time 1584538880
ber_get_next
5e722500 conn=1000 op=0 do_extended
ber_scanf fmt ({m) ber:
5e722500 send_ldap_extended: err=0 oid= len=0
5e722500 send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 16
5e722500 connection_get(16): got connid=1000
5e722500 connection_read(16): checking for input on id=1000
TLS trace: SSL_accept:before SSL initialization
TLS trace: SSL_accept:before SSL initialization
TLS trace: SSL_accept:SSLv3/TLS read client hello
TLS trace: SSL_accept:SSLv3/TLS write server hello
TLS trace: SSL_accept:SSLv3/TLS write change cipher spec
TLS trace: SSL_accept:TLSv1.3 write encrypted extensions
TLS trace: SSL_accept:SSLv3/TLS write certificate
TLS trace: SSL_accept:TLSv1.3 write server certificate verify
TLS trace: SSL_accept:SSLv3/TLS write finished
TLS trace: SSL_accept:TLSv1.3 early data
TLS trace: SSL_accept:error in TLSv1.3 early data
5e722500 connection_get(16): got connid=1000
5e722500 connection_read(16): checking for input on id=1000
TLS trace: SSL_accept:TLSv1.3 early data
TLS trace: SSL_accept:SSLv3/TLS read finished
TLS trace: SSL_accept:SSLv3/TLS write session ticket
TLS trace: SSL_accept:SSLv3/TLS write session ticket
5e722500 connection_read(16): unable to get TLS client DN, error=49 id=1000
Error initializing libuser: could not bind to LDAP server, first attempt as `cn=Manager,dc=rhts,dc=redhat,dc=com': Can't contact LDAP server.
[root@ci-vm-10-0-138-79 CVE-2011-0002-libuser-creates-LDAP-users-with-a-default-password]# 5e722500 connection_get(16): got connid=1000
5e722500 connection_read(16): checking for input on id=1000
ber_get_next
5e722500 ber_get_next on fd 16 failed errno=32 (Broken pipe)
5e722500 connection_close: conn=1000 sd=16


Expected results:
The user should be added into the ldap-server.

Additional info:
It works with openldap-2.4.46-10.el8
#luseradd luser1
LDAP Bind Password: 
5e72226c slap_listener_activate(7): 
5e72226c >>> slap_listener(ldap:///)
5e72226c connection_get(16): got connid=1000
5e72226c connection_read(16): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 29 contents:
5e72226c op tag 0x77, time 1584538220
ber_get_next
5e72226c conn=1000 op=0 do_extended
ber_scanf fmt ({m) ber:
5e72226c send_ldap_extended: err=0 oid= len=0
5e72226c send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 16
5e72226c connection_get(16): got connid=1000
5e72226c connection_read(16): checking for input on id=1000
TLS trace: SSL_accept:before SSL initialization
TLS trace: SSL_accept:before SSL initialization
TLS trace: SSL_accept:SSLv3/TLS read client hello
TLS trace: SSL_accept:SSLv3/TLS write server hello
TLS trace: SSL_accept:SSLv3/TLS write change cipher spec
TLS trace: SSL_accept:TLSv1.3 write encrypted extensions
TLS trace: SSL_accept:SSLv3/TLS write certificate
TLS trace: SSL_accept:TLSv1.3 write server certificate verify
TLS trace: SSL_accept:SSLv3/TLS write finished
TLS trace: SSL_accept:TLSv1.3 early data
TLS trace: SSL_accept:error in TLSv1.3 early data
5e72226c connection_get(16): got connid=1000
5e72226c connection_read(16): checking for input on id=1000
TLS trace: SSL_accept:TLSv1.3 early data
TLS trace: SSL_accept:SSLv3/TLS read finished
TLS trace: SSL_accept:SSLv3/TLS write session ticket
TLS trace: SSL_accept:SSLv3/TLS write session ticket
5e72226c connection_read(16): unable to get TLS client DN, error=49 id=1000
5e72226c connection_get(16): got connid=1000
5e72226c connection_read(16): checking for input on id=1000
---snipped----
ber_flush2: 14 bytes to sd 16
[root@ci-vm-10-0-138-79 CVE-2011-0002-libuser-creates-LDAP-users-with-a-default-password]# 5e72226c connection_get(16): got connid=1000
5e72226c connection_read(16): checking for input on id=1000
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
5e72226c op tag 0x42, time 1584538220
ber_get_next
TLS trace: SSL3 alert read:warning:close notify
5e72226c ber_get_next on fd 16 failed errno=0 (Success)
5e72226c conn=1000 op=24 do_unbind
5e72226c connection_close: conn=1000 sd=16
TLS trace: SSL3 alert write:warning:close notify
Comment 1 Filip Dvorak 2020-03-18 14:07:00 UTC 
Created attachment 1671079 [details]
slapd.conf
Comment 4 Quanah Gibson-Mount 2020-05-22 15:51:11 UTC 
I don't see a bug here.  Section 3.1.3 of RFC4513 only allows for DNS hostnames in the subject field.  IP addresses are only allowed in the subjectAltName field of the certificate.

If this was working in the past, it would generally indicate that OpenLDAP was patched downstream by RH to support non-RFC conformant behavior.
Comment 5 Matus Honek 2020-05-22 17:28:06 UTC 
(In reply to Quanah Gibson-Mount from comment #4)
> I don't see a bug here.  Section 3.1.3 of RFC4513 only allows for DNS
> hostnames in the subject field.  IP addresses are only allowed in the
> subjectAltName field of the certificate.

Indeed, the RFC does not mention IP address could be used in such case. Which renders this bug/request invalid. Thanks for the feedback.

> 
> If this was working in the past, it would generally indicate that OpenLDAP
> was patched downstream by RH to support non-RFC conformant behavior.

I've retested with the latest LTB build and it exhibits the same issue. Also, I do not see any downstream patch that could potentially cause this.
Comment 6 Quanah Gibson-Mount 2020-05-22 17:36:38 UTC 
(In reply to Matus Honek from comment #5)
> > 
> > If this was working in the past, it would generally indicate that OpenLDAP
> > was patched downstream by RH to support non-RFC conformant behavior.
> 
> I've retested with the latest LTB build and it exhibits the same issue.
> Also, I do not see any downstream patch that could potentially cause this.

Hi Matus,

Thanks for following up!  By "exhibits the same issue" do you mean the LTB build correctly rejects a cert with an IP address in the subject, or that it incorrectly accepts the cert?

Thanks,
Quanah
Comment 7 Matus Honek 2020-05-22 19:11:57 UTC 
Created attachment 1691159 [details]
Certificate with IP address in subject

Ah, sorry... With LTB I could successfully accept certificate with IP address (127.0.0.1) in the subject. Thus it incorrectly accepts the certificate wrt. the RFC. The certificate is attached.
Comment 8 Quanah Gibson-Mount 2020-05-22 19:29:11 UTC 
(In reply to Matus Honek from comment #7)
> Created attachment 1691159 [details]
> Certificate with IP address in subject
> 
> Ah, sorry... With LTB I could successfully accept certificate with IP
> address (127.0.0.1) in the subject. Thus it incorrectly accepts the
> certificate wrt. the RFC. The certificate is attached.

Great, thanks!  I'll confirm upstream and file an issue there if I can reproduce.
Comment 9 Quanah Gibson-Mount 2020-05-22 22:42:38 UTC 
(In reply to Quanah Gibson-Mount from comment #8)
> (In reply to Matus Honek from comment #7)
> > Created attachment 1691159 [details]
> > Certificate with IP address in subject
> > 
> > Ah, sorry... With LTB I could successfully accept certificate with IP
> > address (127.0.0.1) in the subject. Thus it incorrectly accepts the
> > certificate wrt. the RFC. The certificate is attached.
> 
> Great, thanks!  I'll confirm upstream and file an issue there if I can
> reproduce.

Hi Matus,

When using startTLS and an ldap conf option of "demand" (I.e., require the cert to be valid), I get an expected failure using OpenLDAP's stock libldap as long as the URI used by the client uses a hostname. I.e.:

ldapsearch ... -ZZ -H ldap://localhost:389 -> fails

but it does work for me if the IP address is used in the URI rather than the hostname.  I.e.:

ldapsearch ... -ZZ -H ldap://127.0.0.1:389 -> succeeds

The latter behavior would still appear to be a bug, but the scope of the issue seems fairly limited.

I have this tracking upstream in https://bugs.openldap.org/show_bug.cgi?id=9267

Regards,
Quanah
Comment 10 Quanah Gibson-Mount 2020-05-26 16:03:07 UTC 
(In reply to Quanah Gibson-Mount from comment #9)
 
> but it does work for me if the IP address is used in the URI rather than the
> hostname.  I.e.:
> 
> ldapsearch ... -ZZ -H ldap://127.0.0.1:389 -> succeeds
> 
> The latter behavior would still appear to be a bug, but the scope of the
> issue seems fairly limited.
> 
> I have this tracking upstream in
> https://bugs.openldap.org/show_bug.cgi?id=9267

Hi Matus,

After digging deeper into the RFCs (and documented in the upstream bug), it is legal/valid for an IP address in subject to work with an LDAP URI as long as the URI is an IP address.

I.e., ldap://127.0.0.1 and the cert has 127.0.0.1 as the subject.

So as far as I can tell, the default OpenLDAP behavior in cert handling is correct.

Regards,
Quanah
Comment 11 Quanah Gibson-Mount 2020-05-26 16:04:01 UTC 
A side note - Given the provided ldap.conf in this ticket which does indeed use an IP address for the URI, this bug is in fact valid and would denote a regression from standard OpenLDAP.

Regards,
Quanah
Comment 23 errata-xmlrpc 2021-11-09 19:49:50 UTC 
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 (openldap bug fix and enhancement update), 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-2021:4449