Hide Forgot
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
Created attachment 1671079 [details] slapd.conf
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.
(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.
(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
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.
(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.
(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
(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
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
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