openldap-bugs April 2019

openldap-bugs@openldap.org

16 participants
64 discussions

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 25 Apr '19

25 Apr '19

--_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wow! Thanks for responding so fast. This could be a bug in docker-openldap = then. we have repro'ed this in two different environments - mac and ubuntu.= Do you have a recommendation for docker image for openldap? ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Wednesday, April 24, 2019 9:42 AM To: Siddharth Jain; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client Siddharth Jain wrote: > we have documented complete steps to repro the bug here <https://eur04.sa= felinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%2= Fopenldap-bug&data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84= df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&sdata=3D8Vf= RtnCNPd%2BFo2Sps%2BLftBG3XcC57ReIFFphK6noyLc%3D&reserved=3D0> with cont= ainer logs. I see no error here. Using your cert/key files: > ls -l /tmp/jnj total 12 -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem -rw-r--r-- 1 hyc hyc 241 Apr 24 17:34 jnj-ldap-server-tls.key -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem ### With this slapd config vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/openldap.schema include ./schema/nis.schema include ./testdata/test.schema pidfile /home/hyc/OD/hobj/tests/testrun/slapd.1.pid argsfile /home/hyc/OD/hobj/tests/testrun/slapd.1.args sockbuf_max_incoming 4194303 TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw secret directory /home/hyc/OD/hobj/tests/testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub maxsize 33554432 database monitor ### And this slapd invocation from the OpenLDAP build tree vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -h l= daps://:9011 -s0 -d7 I get no verification error: > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-chai= n.pem -showcerts CONNECTED(00000005) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN = =3D rca-jnj verify return:1 depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D rca-jnj-admin verify return:1 depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished read R BLOCK --- Certificate chain 0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D jnj-ldap-server i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+ X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7 cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9 AklAHxajASZK+UU=3D -----END CERTIFICATE----- 1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D c= lient + OU =3D jnj, CN =3D rca-jnj-admin i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ=3D -----END CERTIFICATE----- 2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D r= ca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D jnj-ldap-server issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU = =3D client + OU =3D jnj, CN =3D rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2254 bytes and written 391 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8A0A6D6D05FFB544= E91F2 Session-ID-ctx: Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BDB832D9C64834D18= F367E8AD2AD5F9BCF9649330D321DC19D0AB49882 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix...= .xX. 0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5 .x....6....S.'= .. 0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8 ]-(;.&qDe.C...= F. 0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94 ..4W.Bq.Op. .t= .. 0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af .....E.,bJ(.1.= ?. 0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a F|.....|.p..L/= b. 0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2 ...G...q...*.}= .. 0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f !....O..L..w..= d. 0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13 r..E.........F= }. 0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3 .+..=3D....l..= .... 00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a ..+..p...E\#..= j: 00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67 a.:.J6H.....A.= .g 00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0 S......~.9....= .. Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042EB7D0DCEDB8D4CD= 577B5 Session-ID-ctx: Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7E05051224D64669= 3BBD0B964C039185F933442D400BBCBC92A832913 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix...= .xX. 0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c ..(..kK..>.;.N= .l 0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11 ......!M.x,5..= .. 0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89 "Y........T...= .. 0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf ..tq.....\..B#= G. 0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe .V......ie...}= .. 0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df ...d,n.=3D...G= .i.. 0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d ..u...a.&V]..M= -- 0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95 x.em.....E....= .. 0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25 ......f..n?..G= .% 00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4 ....L.d.#>Xg..= ~. 00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23 ..M1@$....?.H.= .# 00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f .S...9y.....qc= ./ Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify vielle:/home/software/openldap-bug> ### There is no OpenLDAP bug here. Your server environment is broken. -- -- Howard Chu CTO, Symas Corp. https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.symas.com&data=3D02%7C01%7C%7Caca4f78e53324b52= 690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369172093154= 07238&sdata=3DyzZvZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&reserv= ed=3D0 Director, Highland Sun https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fhighlandsun.com%2Fhyc%2F&data=3D02%7C01%7C%7Caca4f= 78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63= 6917209315407238&sdata=3Dc%2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%= 3D&reserved=3D0 Chief Architect, OpenLDAP https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&data=3D02%7C01%7C%7C= aca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7C636917209315407238&sdata=3DbMFyP0JzruNwnxXozQQnUVYg2WrYvQJ1PFDWdgkd6= zc%3D&reserved=3D0 --_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> Wow! Thanks for responding so fast. This could be a bug in docker-openldap = then. we have repro'ed this in two different environments - mac and ubuntu.= Do you have a recommendation for docker image for openldap? </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr">From: Howard Chu <hyc@sy= mas.com> Sent: Wednesday, April 24, 2019 9:42 AM To: Siddharth Jain; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client <div> </div> </div> <div class=3D"BodyFragment"> <div class=3D"PlainText">Siddharth Jain wrote: > we have documented complete steps to repro the bug here <<a hr= ef=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D02%7C01%7C%7Caca4f78e533= 24b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63691720= 9315407238&amp;sdata=3D8VfRtnCNPd%2BFo2Sps%2BLftBG3XcC57ReIFFphK6noyLc%= 3D&amp;reserved=3D0">https://eur04.safelinks.protection.outlook.com/?ur= l=3Dhttps%3A%2F%2Fgithub.com%2Fsiddjain%2Fopenldap-bug&amp;data=3D02%7C= 01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa= %7C1%7C0%7C636917209315407238&amp;sdata=3D8VfRtnCNPd%2BFo2Sps%2BLftBG3X= cC57ReIFFphK6noyLc%3D&amp;reserved=3D0</a>> with container logs. I see no error here. Using your cert/key files: > ls -l /tmp/jnj total 12 -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem -rw-r--r-- 1 hyc hyc  241 Apr 24 17:34 jnj-ldap-server-tls.key -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem ### With this slapd config vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf include         ./schema/core.schem= a include         ./schema/cosine.sch= ema include         ./schema/inetorgper= son.schema include         ./schema/openldap.s= chema include         ./schema/nis.schema= include         ./testdata/test.sch= ema pidfile         /home/hyc/OD/hobj/t= ests/testrun/slapd.1.pid argsfile        /home/hyc/OD/hobj/tests/= testrun/slapd.1.args sockbuf_max_incoming 4194303 TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key database        mdb suffix          "dc=3Dexa= mple,dc=3Dcom" rootdn          "cn=3DMan= ager,dc=3Dexample,dc=3Dcom" rootpw          secret directory       /home/hyc/OD/hobj/tests/testr= un/db.1.a index           objectCla= ss     eq index           cn,sn,uid=        pres,eq,sub maxsize 33554432 database        monitor ### And this slapd invocation from the OpenLDAP build tree vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -= h ldaps://:9011 -s0 -d7 I get no verification error: > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-c= hain.pem -showcerts CONNECTED(00000005) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= CN =3D rca-jnj verify return:1 depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin verify return:1 depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished read R BLOCK --- Certificate chain  0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+ X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7<br= > cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9 AklAHxajASZK+UU=3D -----END CERTIFICATE-----  1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, CN =3D rca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ=3D -----END CERTIFICATE-----  2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= CN =3D rca-jnj    i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Joh= nson, CN =3D rca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson,= OU =3D client + OU =3D jnj, CN =3D jnj-ldap-server issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, = OU =3D client + OU =3D jnj, CN =3D rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2254 bytes and written 391 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session:     Protocol  : TLSv1.3     Cipher    : TLS_AES_256_GCM_SHA384     Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8= A0A6D6D05FFB544E91F2     Session-ID-ctx:     Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BD= B832D9C64834D18F367E8AD2AD5F9BCF9649330D321DC19D0AB49882     PSK identity: None     PSK identity hint: None     SRP username: None     TLS session ticket lifetime hint: 7200 (seconds)     TLS session ticket:     0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90&n= bsp;  .~[.=3Do.Ix....xX.     0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5&n= bsp;  .x....6....S.'..     0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8&n= bsp;  ]-(;.&qDe.C...F.     0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94&n= bsp;  ..4W.Bq.Op. .t..     0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af&n= bsp;  .....E.,bJ(.1.?.     0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a&n= bsp;  F|.....|.p..L/b.     0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2&n= bsp;  ...G...q...*.}..     0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f&n= bsp;  !....O..L..w..d.     0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13&n= bsp;  r..E.........F}.     0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3&n= bsp;  .+..=3D....l......     00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a&n= bsp;  ..+..p...E\#..j:     00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67&n= bsp;  a.:.J6H.....A..g     00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0&n= bsp;  S......~.9......     Start Time: 1556123794     Timeout   : 7200 (sec)     Verify return code: 0 (ok)     Extended master secret: no     Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session:     Protocol  : TLSv1.3     Cipher    : TLS_AES_256_GCM_SHA384     Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042= EB7D0DCEDB8D4CD577B5     Session-ID-ctx:     Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7= E05051224D646693BBD0B964C039185F933442D400BBCBC92A832913     PSK identity: None     PSK identity hint: None     SRP username: None     TLS session ticket lifetime hint: 7200 (seconds)     TLS session ticket:     0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90&n= bsp;  .~[.=3Do.Ix....xX.     0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c&n= bsp;  ..(..kK..>.;.N.l     0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11&n= bsp;  ......!M.x,5....     0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89&n= bsp;  "Y........T.....     0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf&n= bsp;  ..tq.....\..B#G.     0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe&n= bsp;  .V......ie...}..     0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df&n= bsp;  ...d,n.=3D...G.i..     0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d&n= bsp;  ..u...a.&V]..M--     0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95&n= bsp;  x.em.....E......     0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25&n= bsp;  ......f..n?..G.%     00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4&n= bsp;  ....L.d.#>Xg..~.     00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23&n= bsp;  ..M1@$....?.H..#     00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f&n= bsp;  .S...9y.....qc./     Start Time: 1556123794     Timeout   : 7200 (sec)     Verify return code: 0 (ok)     Extended master secret: no     Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify vielle:/home/software/openldap-bug> ### There is no OpenLDAP bug here. Your server environment is broken. --   -- Howard Chu   CTO, Symas Corp.        &nbs= p;  <a href=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dh= ttp%3A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7Caca4f78e53324b5269000= 8d6c8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238= &amp;sdata=3DyzZvZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&amp;res= erved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.syma= s.com&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e= 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3DyzZ= vZLe34LJJfhMqjtBoGhJqMXnLSPdeBExlpYnMKqY%3D&amp;reserved=3D0</a>   Director, Highland Sun     <a href=3D"https://eu= r04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighlandsun.com%2F= hyc%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9= e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3Dc%= 2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighland= sun.com%2Fhyc%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc= 09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;= sdata=3Dc%2B1myt04g7sv1kXBUCwd1bUgQV4HGrjAgYgsPoAXLpA%3D&amp;reserved= =3D0</a>   Chief Architect, OpenLDAP  <a href=3D"https://eur04.safelinks.p= rotection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&amp= ;amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c8d3cc09%7C84df9e7fe9f640a= fb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp;sdata=3DbMFyP0JzruNw= nxXozQQnUVYg2WrYvQJ1PFDWdgkd6zc%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.open= ldap.org%2Fproject%2F&amp;data=3D02%7C01%7C%7Caca4f78e53324b52690008d6c= 8d3cc09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917209315407238&amp= ;amp;sdata=3DbMFyP0JzruNwnxXozQQnUVYg2WrYvQJ1PFDWdgkd6zc%3D&amp;reserve= d=3D0</a> </div> </div> </div> </body> </html> --_000_MWHPR08MB2400F5334463D5A204E8CF88B53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 25 Apr '19

25 Apr '19

Siddharth Jain wrote: > we have documented complete steps to repro the bug=A0here <https://gith= ub.com/siddjain/openldap-bug>=A0with container logs. I see no error here. Using your cert/key files: > ls -l /tmp/jnj total 12 -rw-r--r-- 1 hyc hyc 1592 Apr 24 17:34 jnj-ca-chain.pem -rw-r--r-- 1 hyc hyc 241 Apr 24 17:34 jnj-ldap-server-tls.key -rw-r--r-- 1 hyc hyc 1111 Apr 24 17:34 jnj-ldap-server-tls.pem ### With this slapd config vielle:~/OD/hobj/tests> cat testrun/slapd.1.conf include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/openldap.schema include ./schema/nis.schema include ./testdata/test.schema pidfile /home/hyc/OD/hobj/tests/testrun/slapd.1.pid argsfile /home/hyc/OD/hobj/tests/testrun/slapd.1.args sockbuf_max_incoming 4194303 TLSCAcertificatefile /tmp/jnj/jnj-ca-chain.pem TLSCertificateFile /tmp/jnj/jnj-ldap-server-tls.pem TLSCertificateKeyFile /tmp/jnj/jnj-ldap-server-tls.key database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DManager,dc=3Dexample,dc=3Dcom" rootpw secret directory /home/hyc/OD/hobj/tests/testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub maxsize 33554432 database monitor ### And this slapd invocation from the OpenLDAP build tree vielle:~/OD/hobj/tests> ../servers/slapd/slapd -f testrun/slapd.1.conf -h= ldaps://:9011 -s0 -d7 I get no verification error: > openssl s_client -connect localhost:9011 -state -nbio -CAfile jnj-ca-ch= ain.pem -showcerts CONNECTED(00000005) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions depth=3D2 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, C= N =3D rca-jnj verify return:1 depth=3D1 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D rca-jnj-admin verify return:1 depth=3D0 C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:TLSv1.3 read server certificate verify SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished read R BLOCK --- Certificate chain 0 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D jnj-ldap-server i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIUcxrGrCSwJwlQhBEuKztfLgRrtygwCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MjIxNzE0MDBa Fw0yMDA0MjExNzE5MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARutu4G452HY8vYKJLw9VXmIuz+ X1XNNwyI6q7KzzwNmTwzWyHIVzxjqNTsTRqY0L0lLI1cko2LsIACqnJTed7yo4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTPS+Zc8+ZDmpVS9XerpVD1gYL7 cjAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQDBbbexORUa nrBJG8iSkADdOIW/ZOK7kbpLJ4x6GdTO8gIgfzOqW/9ZJKFM3PBls6bEVacoRLX9 AklAHxajASZK+UU=3D -----END CERTIFICATE----- 1 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU =3D= client + OU =3D jnj, CN =3D rca-jnj-admin i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMA0GA1UECxMGY2xpZW50MAoGA1UECxMDam5qMRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ=3D -----END CERTIFICATE----- 2 s:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj i:C =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, CN =3D= rca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, O= U =3D client + OU =3D jnj, CN =3D jnj-ldap-server issuer=3DC =3D US, ST =3D WA, L =3D Bellevue, O =3D Johnson & Johnson, OU= =3D client + OU =3D jnj, CN =3D rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2254 bytes and written 391 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 4E6019F281D63D69D1C800DF4D2441CC918FF4A3AFA8A0A6D6D05FFB5= 44E91F2 Session-ID-ctx: Resumption PSK: A00E7F64B5EA00718122A6F34EF0EC9167F437BDB832D9C64834D= 18F367E8AD2AD5F9BCF9649330D321DC19D0AB49882 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix.= ...xX. 0010 - 00 78 10 a6 94 fb 36 96-f9 8b 17 53 8b 27 14 b5 .x....6....S= .'.. 0020 - 5d 2d 28 3b db 26 71 44-65 c3 43 d6 8e e8 46 a8 ]-(;.&qDe.C.= ..F. 0030 - 05 8a 34 57 c0 42 71 03-4f 70 ad 20 07 74 fc 94 ..4W.Bq.Op. = .t.. 0040 - e8 e4 9d 89 d0 45 db 2c-62 4a 28 b6 31 f9 3f af .....E.,bJ(.= 1.?. 0050 - 46 7c f7 f8 9f b1 0b 7c-ea 70 a1 f0 4c 2f 62 0a F|.....|.p..= L/b. 0060 - e3 e9 83 47 0e f2 e5 71-a5 0c ba 2a 8d 7d f8 e2 ...G...q...*= .}.. 0070 - 21 84 1a 1a 86 4f 02 0a-4c 9a 17 77 af 9e 64 1f !....O..L..w= ..d. 0080 - 72 c5 e5 45 d1 bb 92 0a-ae fe e9 b1 bc 46 7d 13 r..E........= .F}. 0090 - aa 2b 9b c1 3d 92 8b 1d-08 6c 11 12 a0 b7 c8 a3 .+..=3D....l= ...... 00a0 - b2 bb 2b d9 bd 70 86 0d-91 45 5c 23 b6 b0 6a 3a ..+..p...E\#= ..j: 00b0 - 61 1d 3a c1 4a 36 48 b4-b3 03 a9 8b 41 94 fd 67 a.:.J6H.....= A..g 00c0 - 53 a6 03 a4 ab c6 a0 7e-e9 39 98 a8 c9 01 bc c0 S......~.9..= .... Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: A7B81922756F8F5B986C7B38E0F29399F8127F52D042EB7D0DCEDB8D4= CD577B5 Session-ID-ctx: Resumption PSK: 5FDD5DF642126A4F04D05EBBECDBB92BBCBAB6A7E05051224D646= 693BBD0B964C039185F933442D400BBCBC92A832913 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - ea 7e 5b e0 3d 6f 9f 49-78 07 f5 c0 da 78 58 90 .~[.=3Do.Ix.= ...xX. 0010 - d3 10 28 b9 01 6b 4b 92-1e 3e ae 3b 7f 4e cc 6c ..(..kK..>.;= .N.l 0020 - 19 d3 0b ac 9c b9 21 4d-ed 78 2c 35 d3 03 ba 11 ......!M.x,5= .... 0030 - 22 59 1c 0d 91 a5 da 93-a0 0a 54 88 aa 81 be 89 "Y........T.= .... 0040 - e0 2e 74 71 8e c8 fd f7-9d 5c 99 15 42 23 47 cf ..tq.....\..= B#G. 0050 - 0d 56 97 10 f3 f8 02 fe-69 65 e6 1c fa 7d 96 fe .V......ie..= .}.. 0060 - 86 d2 c2 64 2c 6e 96 3d-14 e2 87 47 91 69 ef df ...d,n.=3D..= .G.i.. 0070 - 14 d5 75 0d ff da 61 04-26 56 5d 8b d3 4d 2d 2d ..u...a.&V].= .M-- 0080 - 78 fa 65 6d ad ef 15 ba-14 45 f0 ba a6 85 fb 95 x.em.....E..= .... 0090 - dc e5 9b 1c ac e4 66 de-c2 6e 3f e7 1e 47 09 25 ......f..n?.= .G.% 00a0 - 89 b0 c3 c0 4c 93 64 de-23 3e 58 67 ae f3 7e e4 ....L.d.#>Xg= ..~. 00b0 - d5 af 4d 31 40 24 87 da-ec e7 3f 8a 48 b5 9d 23 ..M1@$....?.= H..# 00c0 - d4 53 01 fa 18 39 79 0f-9b 9c ea ed 71 63 c5 2f .S...9y.....= qc./ Start Time: 1556123794 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- SSL_connect:SSLv3/TLS read server session ticket read R BLOCK SSL3 alert read:warning:close notify closed SSL3 alert write:warning:close notify vielle:/home/software/openldap-bug> ### There is no OpenLDAP bug here. Your server environment is broken. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 25 Apr '19

25 Apr '19

--_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable we have documented complete steps to repro the bug here<https://github.com/= siddjain/openldap-bug> with container logs. ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Monday, April 22, 2019 10:15 AM To: siddjain(a)live.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate bef= ore sending it to client siddjain(a)live.com wrote: > Full_Name: SIDDHARTH JAIN > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.226.196.10) > > > In some cases, OpenLDAP will modify the TLS certificate given to it befor= e > sending it over to the client resulting in a certificate signature error.= An > example of certificate it modifies is given below: OpenLDAP never touches the certificates you configure. If you're getting a = corrupted certificate then there's either a bug in your storage/filesystem or in your= SSL/TLS library. -- -- Howard Chu CTO, Symas Corp. https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.symas.com&data=3D02%7C01%7C%7Cb0dec02e090a48ff= 954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6369155015543= 63548&sdata=3D7ca82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&reserv= ed=3D0 Director, Highland Sun https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fhighlandsun.com%2Fhyc%2F&data=3D02%7C01%7C%7Cb0dec= 02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63= 6915501554363548&sdata=3DFr3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDR= GNjx8Lo%3D&reserved=3D0 Chief Architect, OpenLDAP https://eur04.safelinks.protection.outlook.com= /?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&data=3D02%7C01%7C%7C= b0dec02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0= %7C636915501554373561&sdata=3DJ%2B926RRaeQIx6%2BIvx70BnHqZ0zj4SO5ilR6VP= vdiTsk%3D&reserved=3D0 --_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0);"> <span style=3D"color: rgb(36, 41, 46); font-family: -apple-system, system-u= i, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Em= oji", "Segoe UI Emoji", "Segoe UI Symbol"; font-si= ze: 14px; background-color: rgb(255, 255, 255); display: inline !important"= >we have documented complete steps to repro the bug <= a href=3D"https://github.com/siddjain/openldap-bug" style=3D"box-sizing: bo= rder-box; background-color: rgb(255, 255, 255); color: rgb(3, 102, 214); fo= nt-family: -apple-system, system-ui, "Segoe UI", Helvetica, Arial= , sans-serif, "Apple Color Emoji", "Segoe UI Emoji", &q= uot;Segoe UI Symbol"; font-size: 14px">here</a><span style=3D"color: r= gb(36, 41, 46); font-family: -apple-system, system-ui, "Segoe UI"= , Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe = UI Emoji", "Segoe UI Symbol"; font-size: 14px; background-co= lor: rgb(255, 255, 255); display: inline !important"> wit= h container logs. </div> <div> <div id=3D"appendonsend"></div> <div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col= or:rgb(0,0,0)"> </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"divRplyFwdMsg" dir=3D"ltr">From: Howard Chu <hyc@sy= mas.com> Sent: Monday, April 22, 2019 10:15 AM To: siddjain(a)live.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9014) OpenLDAP modifies user provided TLS certific= ate before sending it to client <div> </div> </div> <div class=3D"BodyFragment"> <div class=3D"PlainText">siddjain(a)live.com wrote: > Full_Name: SIDDHARTH JAIN > Version: 2.4.45 > OS: Linux > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a> > Submission from: (NULL) (173.226.196.10) > > > In some cases, OpenLDAP will modify the TLS certificate given to it be= fore > sending it over to the client resulting in a certificate signature err= or. An > example of certificate it modifies is given below: OpenLDAP never touches the certificates you configure. If you're getting a = corrupted certificate then there's either a bug in your storage/filesystem or in your= SSL/TLS library. --   -- Howard Chu   CTO, Symas Corp.        &nbs= p;  <a href=3D"https://eur04.safelinks.protection.outlook.com/?url=3Dh= ttp%3A%2F%2Fwww.symas.com&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b0= 8d6c7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548= &amp;sdata=3D7ca82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&amp;res= erved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.syma= s.com&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9e= 7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;sdata=3D7ca= 82woC2PGsf9x0qYDT1izZ5MSqJbxA4T9m8kq5y2Y%3D&amp;reserved=3D0</a>   Director, Highland Sun     <a href=3D"https://eu= r04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighlandsun.com%2F= hyc%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9= e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;sdata=3DFr= 3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDRGNjx8Lo%3D&amp;reserved=3D0= "> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fhighland= sun.com%2Fhyc%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462d= a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554363548&amp;= sdata=3DFr3v%2FI3WSXtWqXOFDY%2F9Z4%2FqS%2F%2FvC4YMJQDRGNjx8Lo%3D&amp;re= served=3D0</a>   Chief Architect, OpenLDAP  <a href=3D"https://eur04.safelinks.p= rotection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.openldap.org%2Fproject%2F&amp= ;amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c7462da0%7C84df9e7fe9f640a= fb435aaaaaaaaaaaa%7C1%7C0%7C636915501554373561&amp;sdata=3DJ%2B926RRaeQ= Ix6%2BIvx70BnHqZ0zj4SO5ilR6VPvdiTsk%3D&amp;reserved=3D0"> https://eur04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.open= ldap.org%2Fproject%2F&amp;data=3D02%7C01%7C%7Cb0dec02e090a48ff954b08d6c= 7462da0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636915501554373561&amp= ;amp;sdata=3DJ%2B926RRaeQIx6%2BIvx70BnHqZ0zj4SO5ilR6VPvdiTsk%3D&amp;res= erved=3D0</a> </div> </div> </div> </body> </html> --_000_MWHPR08MB24001BB2C0F56927A628AF69B53C0MWHPR08MB2400namp_--

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by ondra＠mistotebe.net 24 Apr '19

24 Apr '19

On Tue, Apr 23, 2019 at 11:28:40PM +0000, quanah(a)symas.com wrote: > --On Tuesday, April 23, 2019 8:56 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 > <ondra(a)mistotebe.net> wrote: >> Going by what I think I remember of the consumer code did: >> - on set up, it finds out there's no cookie to go by so it goes into >> refresh on the main DB >> - main DB responds with success but no/empty cookie >> - consumer starts over but again finds itself with no cookie, so it goes >> to step one >> >> But the consumer is actually up to date at that point as the search >> suggested, so it should just go ahead and do the refreshAndPersist on >> accesslog as it planned to originally. And as operations hit the main >> DB, they will replicate accordingly, even if that were to happen after >> the original search and before this one[0]. > > The consumer did not replicate the database as a part of the initial > search, so I don't think it qualifies as "up to date". I.e., it's primary > DB remains empty. Ah, that wasn't mentioned, my assumption was that the source DB was actually empty. This is coming from ITS#8281 fix in cd8ff37629012c1676ef79de164a159da9b2ae89. There are two scenarios that need different treatment: 1. We start with no servers and no data and want to set up MMR from there 2. We start with a live server and want to move over to MMR The bootstrap scenario is the one I outlined in my response above, the consumers should be able to deal with it correctly if they do what I say. However the provider should make it possible for the client to know that's what's happening, so it should only send an empty cookie-less response in the case DB is empty. The conversion to MMR should be dealt with differently. AFAIK, the correct order of set up is: - prepare original master: - serverID == 0 - add syncprov - change serverID accordingly - connect other servers: - set serverIDs - add olcSyncrepl everywhere (including original master) - wait for things to settle, you're done I agree it is necessary we make sure not following the above still results either with a helpful error or that it also Just Works(tm). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9016) cn=config should fail on EMIT if target directory not empty
by michael＠stroeder.com 24 Apr '19

24 Apr '19

This is a cryptographically signed message in MIME format. --------------ms030705030102060301060203 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/24/19 1:32 PM, ondra(a)openldap.org wrote: > Since it's not feasible to clean up properly, it should just return an = error > instead? Yes. In general I prefer fail-early-fail-hard with clear error messages. Ciao, Michael. --------------ms030705030102060301060203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyEwggUzMIIEG6ADAgECAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTYwMDAw MDBaFw0xOTEyMTYyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ryb2VkZXIu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdaCPHlSjB9Wb51jh60x+6OO lOP14FSXRNDYWcuaCwey30JdrJxw9VMiBEJo7Q7fHWcpna9l9oVKuvjO3VepiyTlQoinvwSG gQrBburWskKupOJPwv0QH8nWpc9KnP7LnOqfepwHNrqhweijxeGg95TQeDfOVbQmGwqnaCtp CBuCu3gyxe/wVkKnr6uqwHFUoGSNIrLAdLFcnFbpKGoYvZvahkdLNglCRLpeSVu9/O0MqkGt gGp6nPcTHwbZYSoGqFJQjPeTlczubTKo9DWYhZ0vMB2fjdadSqZxUgqqdElLRWSqRD1jCm3U xShVkPJDQg3tkQq6Yw4C1Z9+L9KxJQIDAQABo4IB6jCCAeYwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLn0/ESCAOEV6clL6lYXzOwKIKlyMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDQYJKoZIhvcNAQELBQADggEB ALFD55CXI+vy81ngFjheHu+TjKJuxrYfw71qz54pmYwR4UYBTSLNvESJXwOfSi7UxBh97xjB bjy5rDByXl1IWAFXcnoHPKJNZL8wOa0MNz4o3X0of7JHZHYlyXJRnZV90+KtZQdn5ZP2hBmg SHxcjdgCMU9p6VoOlJLhpEKN1TmbHq/elcwZKknnGN+54Vn2RhVP0x3998yyhIkiHNAqQImT cqY5QkpGxyocLz54NXudIZSvXyvQI4d7FYl4JKn6gw4PRXht0/xzB/GGGKGWSrgdPCUJ4Rif cGpO43inEBxWlW19cjYSXjqZetq2ZIJnrADxTttTJoUQsGuoT5ZMf2UwggXmMIIDzqADAgEC AhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra 0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr 5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTq Rvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB ADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FB ZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0G CSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj 6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxm gUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTC kk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlL WPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzOb XYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtF OI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3C VJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wk yk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDUwggQxAgEB MIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmH IQX8SWTc7x5fq9i6IjANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDI0MTIwMzU1WjAvBgkqhkiG9w0BCQQxIgQgn56E SGO4wXtKJNZ055HSw53D3LbVbJTHd7PGKrb0KSkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmHIQX8SWTc 7x5fq9i6IjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBAQUA BIIBAJD4gv8eWV6VCHuVWTALdiWdt2YNBvDN7tyVNwURCnW+mlB9gPxBR1uJMp2L49dEdESO 0Dg/A61z0sO35S0wJYCLU8L7RuNahsjkZg8/CSaAPpnbG2xs3jaLNzhaPb1WULR9qbNyJ8dp xwdMSp19gMNUpgTLmHYmsTeAvtujjp4eZwh9VufCbcFstJOMWYO2fyBpJilG4RIouM2bPCLo ii4tAzSDONIeF7W1W1G73xLkw1lmSS4N1zBg1dFJgMTp9bcrGkBqzJajrpeWN2nUGuZBl+xi ucV4w8hezAnVVE8UFofDxn8i1JPsMoCjr1tBcSQg4NQzA5p3nnrOb5ERpDcAAAAAAAA= --------------ms030705030102060301060203--

1 0

(ITS#9016) cn=config should fail on EMIT if target directory not empty
by ondra＠openldap.org 24 Apr '19

24 Apr '19

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (82.10.24.68) Running slapd/slaptest to convert a slapd.conf to cn=config will happily reuse the target directory. However if there was some existing configuration present already, slaptest reports a successful conversion, even though the resulting directory most likely won't represent the slapd.conf used - existing .ldif files won't be replaced or removed. Depending on the differences between slapd.conf and slapd.d in place, the result might not even be a useable cn=config anymore. Since it's not feasible to clean up properly, it should just return an error instead?

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by quanah＠symas.com 24 Apr '19

24 Apr '19

--On Tuesday, April 23, 2019 8:56 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 <ondra(a)mistotebe.net> wrote: > Going by what I think I remember of the consumer code did: > - on set up, it finds out there's no cookie to go by so it goes into > refresh on the main DB > - main DB responds with success but no/empty cookie > - consumer starts over but again finds itself with no cookie, so it goes > to step one > > But the consumer is actually up to date at that point as the search > suggested, so it should just go ahead and do the refreshAndPersist on > accesslog as it planned to originally. And as operations hit the main > DB, they will replicate accordingly, even if that were to happen after > the original search and before this one[0]. The consumer did not replicate the database as a part of the initial=20 search, so I don't think it qualifies as "up to date". I.e., it's primary=20 DB remains empty. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by ondra＠mistotebe.net 24 Apr '19

24 Apr '19

On Tue, Apr 23, 2019 at 04:48:28PM +0000, quanah(a)openldap.org wrote: > In testing a particular use case/setup scenario, I found that it's possible to > cause a replica to slam a provider with unending requests. In this specific > case, I was setting up delta-syncrepl MMR, but I believe the issue applies to > standard syncrepl, and is not MMR specific. The scenario looks like this: > > Initially we have a stand alone server, which no overlays in place. The > configuration is done via cn=config, which allows for us to update the > configuration without a server restart. > > [...] > > I believe the problem is that the root entry for the database contains no > contextCSN. This is likely due to the fact that: > > [...] > > However, I think the overall behavior is undesirable. If there is no contextCSN > present, it should not lead to replication clients executing a potential DoS on > the provider. It also generated ~60GB of logs at loglevel stats in 1 day. Ok, I think this is consumer's fault and limited to refreshAndPersist deltasync (with or without MMR). Going by what I think I remember of the consumer code did: - on set up, it finds out there's no cookie to go by so it goes into refresh on the main DB - main DB responds with success but no/empty cookie - consumer starts over but again finds itself with no cookie, so it goes to step one But the consumer is actually up to date at that point as the search suggested, so it should just go ahead and do the refreshAndPersist on accesslog as it planned to originally. And as operations hit the main DB, they will replicate accordingly, even if that were to happen after the original search and before this one[0]. So in that case the behaviour would be as follows: - on set up, it finds out there's no cookie to go by so it goes into refresh on the main DB - main DB responds with success but no/empty cookie - consumer starts over, remembering that its cookie (albeit empty) is valid, so sends a refreshAndPersist search on accesslog DB - that yields no traffic, but will give it the right data once anything replication-worthy happens, job done - unless the connection is actually severed (restarts, ...) before anything needs replicating, we start from step one but no overhead was incurred, we're still fine [0]. Unless so much time has elapsed between the two searches (that happen on the same connection BTW) that some accesslog ops have already been expired. Expiration is usually configured in days, not seconds and an admin that doesn't notice a consumer going AWOL for that amount of time probably deserves that. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by quanah＠symas.com 24 Apr '19

24 Apr '19

--On Tuesday, April 23, 2019 7:07 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > The consumer should not be reconnecting more frequently than its retry > config. Since the consumer never disconnects, there is no reconnect. It connects a single time, and issues the same operation endlessly. Thus why when you look at the log file snippet I pasted, you see an OPERATION count in the MILLIONS. conn=1003 op=361869515 I.e., OPERATION 361,869,515 for connection 1003. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9015) Replication goes haywire querying promoted master
by hyc＠symas.com 24 Apr '19

24 Apr '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.144.40) > > > In testing a particular use case/setup scenario, I found that it's possible to > cause a replica to slam a provider with unending requests. In this specific > case, I was setting up delta-syncrepl MMR, but I believe the issue applies to > standard syncrepl, and is not MMR specific. The scenario looks like this: > > Initially we have a stand alone server, which no overlays in place. The > configuration is done via cn=config, which allows for us to update the > configuration without a server restart. > > The configuration is modified to load the syncprov and accesslog overlays, > create a new accesslog database, and to send all change data to the accesslog > db. > > After that is done, a secondary server is brought online with the same > configuration other than the serverID being different and the syncrepl statement > adjusted. > > When the secondary server is started, it pummels the initial provider with > queries like: > > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH > base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH attr=* + > Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SEARCH RESULT > tag=101 err=0 nentries=0 text= > > (Averaging around 2000 queries/second on my server per syncrepl client). > > I believe the problem is that the root entry for the database contains no > contextCSN. This is likely due to the fact that: > > a) There was never a syncprov overlay present until I loaded this one in > b) The serverID was set prior to the syncprov overlay being loaded (So it went > from "0" to "1", with no changes ever recorded for "1"). > > Now there is a trivial ways to handle this, by making a change on the provider > prior to starting up the other servers. > > However, I think the overall behavior is undesirable. If there is no contextCSN > present, it should not lead to replication clients executing a potential DoS on > the provider. It also generated ~60GB of logs at loglevel stats in 1 day. The consumer should not be reconnecting more frequently than its retry config. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2019