Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-25 Thread Bastian Tweddell 
On 21Oct21 18:39+0300, Nick Milas wrote:
> It shows that the CA/cert has issues. Yet, everything was working fine 
> until last upgrade!

Check your ldaprc for TLS_REQCERT. Maybe that changed in the upgrade?

-- 
Bastian TweddellJuelich Supercomputing Centre


smime.p7s
Description: S/MIME cryptographic signature

Antw: [EXT] Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-22 Thread Ulrich Windl 
>>> Quanah Gibson-Mount  schrieb am 21.10.2021 um 19:29 in
Nachricht <125627C2D6AF4AE00EF3FCDF@[192.168.1.11]>:

> 
> --On Thursday, October 21, 2021 7:54 PM +0300 Nick Milas 
>  wrote:
> 
>> On 21/10/2021 6:39 μ.μ., Nick Milas wrote:
>>
>>> From the journal, some excerpts (it is very long):
>>
>> My fault: I copied parts from the journal before the restart :(
>>
>> Here is the actual log after restart:
> 
> The client side still says it can't validate the cert.  As long as the 
> client can't validate the cert, you won't be able to establish TLS.
> 
>>From your ldapwhoami output:
> 
> TLS certificate verification: depth: 0, err: 20, subject: 
> /C=GR/ST=Attik\xC3\xAD/L=Athens/O=National Observatory of 
> Athens/CN=ldap1.noa.gr, issuer: /C=NL/O=GEANT Vereniging/CN=GEANT OV RSA CA

> 4
> TLS certificate verification: Error, unable to get local issuer certificate

Maybe use openssl x509 to display the certificate chain, looking for problems,
and use the "verify" of openssl to check the certificate (chain).
And show us the results ;-)

> 
> --Quanah
> 
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
>

Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Quanah Gibson-Mount 




--On Thursday, October 21, 2021 7:54 PM +0300 Nick Milas 
 wrote:



On 21/10/2021 6:39 μ.μ., Nick Milas wrote:


From the journal, some excerpts (it is very long):


My fault: I copied parts from the journal before the restart :(

Here is the actual log after restart:


The client side still says it can't validate the cert.  As long as the 
client can't validate the cert, you won't be able to establish TLS.



From your ldapwhoami output:


TLS certificate verification: depth: 0, err: 20, subject: 
/C=GR/ST=Attik\xC3\xAD/L=Athens/O=National Observatory of 
Athens/CN=ldap1.noa.gr, issuer: /C=NL/O=GEANT Vereniging/CN=GEANT OV RSA CA 
4

TLS certificate verification: Error, unable to get local issuer certificate

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Nick Milas 

On 21/10/2021 6:39 μ.μ., Nick Milas wrote:


From the journal, some excerpts (it is very long):


My fault: I copied parts from the journal before the restart :(

Here is the actual log after restart:

Oct 21 18:31:28 ldap.noa.gr systemd[1]: slapd.service start operation 
timed out. Terminating.
Oct 21 18:31:28 ldap.noa.gr slapd[24898]: daemon: shutdown requested and 
initiated.
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: shutdown 
requested and initiated.

Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: closing 7
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: closing 8
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: closing 9
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: closing 10
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: closing 11
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 
connection_closing: readying conn=1004 sd=15 for close
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 connection_close: 
conn=1004 sd=15

Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 daemon: removing 15
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: tls_write: want=31, written=31
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: :  15 03 03 00 1a 76 
bc 75  b6 cd d1 37 29 11 a2 d8   .v.u...7)...
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 0010:  7b 5c 1d fc 07 73 
a7 ce  46 05 d2 04 d2 29 8b  {\...s..F).
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: TLS trace: SSL3 alert 
write:warning:close notify
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 conn=1004 fd=15 
closed (slapd shutdown)
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 slapd shutdown: 
waiting for 0 operations/tasks to finish
Oct 21 18:31:28 ldap.noa.gr slapd-cli[24796]: 617187d0 slapd shutdown: 
initiated
Oct 21 18:31:28 ldap.noa.gr slapd[24898]: conn=1004 fd=15 closed (slapd 
shutdown)
Oct 21 18:31:28 ldap.noa.gr slapd[24898]: slapd shutdown: waiting for 0 
operations/tasks to finish

Oct 21 18:31:28 ldap.noa.gr slapd[24898]: slapd stopped.
Oct 21 18:31:28 ldap.noa.gr systemd[1]: Failed to start OpenLDAP LTB 
startup script.

-- Subject: Unit slapd.service has failed

Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Howard Chu 
Nick Milas wrote:
> Thank you for the reply:
> 
> Here it is:

> It shows that the CA/cert has issues. Yet, everything was working fine until 
> last upgrade!

Well, it's not going to lie to you. Your CA cert isn't recognized, so some 
other upgrade must
have mucked with your certs or LDAP config. Simple enough to fix, just make 
sure the CA cert
you're using is present in the expected cert dir.
> 
> Nick
> 
> 
> On 21/10/2021 6:20 μ.μ., Howard Chu wrote:
> 
>> Run ldapwhoami with -d -1. Also run slapd with -d -1.
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Nick Milas 

Thank you for the reply:

Here it is:

# ldapwhoami -H ldaps://ldap.noa.gr:636 -x -d -1
ldap_url_parse_ext(ldaps://ldap.noa.gr:636)
ldap_create
ldap_url_parse_ext(ldaps://ldap.noa.gr:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.noa.gr:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 2001:648:2011:10::234 636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS trace: SSL_connect:before/connect initialization
tls_write: want=289, written=289
  :  16 03 01 01 1c 01 00 01  18 03 03 18 6f 98 e6 4e o..N
  0010:  cb a4 18 3c d7 ea 88 43  1d 28 de ef 3c d9 a0 5a ...<...C.(..<..Z
  0020:  8b a4 cb a1 eb 4b be 96  7f 5a 78 00 00 ac c0 30 .K...Zx0
  0030:  c0 2c c0 28 c0 24 c0 14  c0 0a 00 a5 00 a3 00 a1 .,.(.$..
  0040:  00 9f 00 6b 00 6a 00 69  00 68 00 39 00 38 00 37 ...k.j.i.h.9.8.7
  0050:  00 36 00 88 00 87 00 86  00 85 c0 32 c0 2e c0 2a .6.2...*
  0060:  c0 26 c0 0f c0 05 00 9d  00 3d 00 35 00 84 c0 2f .&...=.5.../
  0070:  c0 2b c0 27 c0 23 c0 13  c0 09 00 a4 00 a2 00 a0 .+.'.#..
  0080:  00 9e 00 67 00 40 00 3f  00 3e 00 33 00 32 00 31 ...g.@.?.>.3.2.1
  0090:  00 30 00 9a 00 99 00 98  00 97 00 45 00 44 00 43 .0.E.D.C
  00a0:  00 42 c0 31 c0 2d c0 29  c0 25 c0 0e c0 04 00 9c .B.1.-.).%..
  00b0:  00 3c 00 2f 00 96 00 41  c0 12 c0 08 00 16 00 13 .<./...A
  00c0:  00 10 00 0d c0 0d c0 03  00 0a 00 07 c0 11 c0 07 
  00d0:  c0 0c c0 02 00 05 00 04  00 ff 01 00 00 43 00 0b .C..
  00e0:  00 04 03 00 01 02 00 0a  00 0a 00 08 00 17 00 19 
  00f0:  00 18 00 16 00 23 00 00  00 0d 00 20 00 1e 06 01 .#. 
  0100:  06 02 06 03 05 01 05 02  05 03 04 01 04 02 04 03 
  0110:  03 01 03 02 03 03 02 01  02 02 02 03 00 0f 00 01 
  0120:  01 .
TLS trace: SSL_connect:SSLv2/v3 write client hello A
tls_read: want=7, got=7
  :  16 03 03 00 3a 02 00 :..
tls_read: want=56, got=56
  :  00 36 03 03 0b 75 dd 97  fc f5 46 4d 2c ec d5 a5 .6...uFM,...
  0010:  8b af e0 e1 df 40 58 d1  15 96 12 27 70 24 d7 24 .@X'p$.$
  0020:  30 5d 7d ed 00 00 9d 00  00 0e ff 01 00 01 00 00 0]}.
  0030:  23 00 00 00 0f 00 01 01 #...
TLS trace: SSL_connect:SSLv3 read server hello A
tls_read: want=5, got=5
  :  16 03 03 08 8c .
tls_read: want=2188, got=2188
  :  0b 00 08 88 00 08 85 00  08 82 30 82 08 7e 30 82 ..0..~0.
  0010:  06 66 a0 03 02 01 02 02  11 00 93 7d a9 90 df b3 .f.}
  0020:  39 42 b7 c4 88 39 d4 c6  c7 10 30 0d 06 09 2a 86 9B...90...*.
  0030:  48 86 f7 0d 01 01 0c 05  00 30 44 31 0b 30 09 06 H0D1.0..
  0040:  03 55 04 06 13 02 4e 4c  31 19 30 17 06 03 55 04 .UNL1.0...U.
  0050:  0a 13 10 47 45 41 4e 54  20 56 65 72 65 6e 69 67 ...GEANT Verenig
  0060:  69 6e 67 31 1a 30 18 06  03 55 04 03 13 11 47 45 ing1.0...UGE
  0070:  41 4e 54 20 4f 56 20 52  53 41 20 43 41 20 34 30   ANT OV RSA 
CA 40

  0080:  1e 17 0d 32 31 30 38 32  30 30 30 30 30 30 30 5a ...21082000Z
  0090:  17 0d 32 32 30 38 32 30  32 33 35 39 35 39 5a 30 ..220820235959Z0
  00a0:  70 31 0b 30 09 06 03 55  04 06 13 02 47 52 31 10 p1.0...UGR1.
  00b0:  30 0e 06 03 55 04 08 0c  07 41 74 74 69 6b c3 ad 0...UAttik..
  00c0:  31 0f 30 0d 06 03 55 04  07 13 06 41 74 68 65 6e 1.0...UAthen
  00d0:  73 31 27 30 25 06 03 55  04 0a 13 1e 4e 61 74 69 s1'0%..UNati
  00e0:  6f 6e 61 6c 20 4f 62 73  65 72 76 61 74 6f 72 79   onal 
Observatory
  00f0:  20 6f 66 20 41 74 68 65  6e 73 31 15 30 13 06 03    of 
Athens1.0...

  0100:  55 04 03 13 0c 6c 64 61  70 31 2e 6e 6f 61 2e 67 Uldap1.noa.g
  0110:  72 30 82 02 22 30 0d 06  09 2a 86 48 86 f7 0d 01 r0.."0...*.H
  0120:  01 01 05 00 03 82 02 0f  00 30 82 02 0a 02 82 02 .0..
  0130:  01 00 ae 7f b9 26 59 5c  79 c8 c5 cb a2 dd fa 81 .\y...
  0140:  d9 04 5a 86 07 e9 64 bd  2e 8a 72 ab d8 27 43 a8 ..Z...d...r..'C.
  0150:  6c 90 4f 18 88 ab 1b 9f  47 84 1f 23 28 85 ba 0c l.O.G..#(...
  0160:  a4 18 3a 0c 81 dc 51 78  2a 66 22 fb 96 e8 81 eb ..:...Qx*f".
  0170:  57 1a 98 dc 44 f2 96 9b  36 b6 ab 35 d1 ae af de W...D...6..5
  0180:  84 84 47 b4 93 82 17 44  b4 83 d3 9c 16 0a 05 37 ..GD...7
  0190:  a6 50 3a f2 5e 72 d7 34  63 28 db 1d 4e 60 d8 db .P:.^r.4c(..N`..
  01a0:  21 1b 91 74 b5 16 6b d2  fe 2a 00 74 a8 1e b9 6b !..t..k..*.t...k
  01b0:  1c 0e 5d 7e 14 1b aa 2e  50 9d fa c4 45 3f d1 97 ..]~P...E?..
  01c0:  06 a8 ba c2 00 ee 07 d3  f9 45 59 3a b9 95 b2 4b .EY:...K
  01d0:  de fb 1e 35 c4 94 a4 3b  b3 68 b9 14 52 a9 2a dc ...5...;.h..R.*.
  01e0:  1a e2 a8 95 86 b7 15 22  78 a5 30 27 39 e9 f6 a7 ..."x.0'9...
  01f0:  e8 e1 ee f2 89 fa df 49  06 7f 6d c3 d0 43 7e 7f ...I..m..C~.
  0200:  8f ef 2f 05 84 52 f3 55  19 fd 20

Re: Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Howard Chu 
Nick Milas wrote:
> Hello,
> 
> Our main OpenLDAP Server (running on CentOS 7) has been working fine with 
> 2.4.58.
> 
> Since yesterday, after a (minor, see at the end) OS upgrade which included an 
> update to LTB Openldap 2.4.59, SSL clients see:
> 
> # ldapwhoami -H ldaps://ldap.noa.gr:636 -x
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Run ldapwhoami with -d -1. Also run slapd with -d -1.


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Problem with SSL/TLS on CentOS 7 after upgrading to 2.4.59

2021-10-21 Thread Nick Milas 

Hello,

Our main OpenLDAP Server (running on CentOS 7) has been working fine 
with 2.4.58.


Since yesterday, after a (minor, see at the end) OS upgrade which 
included an update to LTB Openldap 2.4.59, SSL clients see:


# ldapwhoami -H ldaps://ldap.noa.gr:636 -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

In the log I see, for example:

Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 ACCEPT from 
IP=195.251.xxx.xxx:44016 (IP=0.0.0.0:389)
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 EXT 
oid=1.3.6.1.4.1.1466.20037

Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 STARTTLS
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 op=0 RESULT oid= err=0 text=
Oct 21 17:10:58 ldap slapd[18532]: conn=1170 fd=18 closed (TLS 
negotiation failure)

...
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 ACCEPT from 
IP=[2001:648:2011:::]:52018 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 TLS established 
tls_ssf=256 ssf=256
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND 
dn="uid=full,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 BIND 
dn="uid=Full,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0

Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=0 RESULT tag=97 err=0 text=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH 
base="dc=noa,dc=gr" scope=2 deref=0 filter="(objectClass=*)"

Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 SRCH attr=* +
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search: 
got a persistent search with a 
cookie=rid=601,csn=20200910151806.461875Z#00#000#00
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findbase: 
searching
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_op_search: 
registered persistent search
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: 
mode=FIND_CSN csn=20200910151806.461875Z#00#000#00
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: 
csn==20200910151806.461875Z#00#000#00 not found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: 
csn<=20200910151806.461875Z#00#000#00 found
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_findcsn: 
mode=FIND_PRESENT csn=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo: 
present syncIdSet cookie=
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 INTERM 
oid=1.3.6.1.4.1.4203.1.9.1.4
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 op=1 syncprov_sendinfo: 
present syncIdSet cookie=

...
Oct 21 17:11:34 ldap slapd[18532]: send_search_entry: conn 1172 ber 
write failed.
Oct 21 17:11:34 ldap slapd[18532]: conn=1172 fd=18 closed (connection 
lost on write)

Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!
Oct 21 17:11:34 ldap slapd[18532]: connection_read(18): no connection!

...

Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 ACCEPT from 
IP=[2001:648:2011:::]:33466 (IP=[::]:636)
Oct 21 17:11:34 ldap slapd[18532]: conn=1173 fd=18 closed (TLS 
negotiation failure)


Is there some settings change in 2.4.59 or something is getting wrong?

My settings:

olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv.crt
olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert.crt
olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/GeantCA.crt

I also tried:

olcTLSCipherSuite: ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

without success.

Interestingly, I can see random successes like:

Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 ACCEPT from 
IP=[2001:648:2011:::]:47206 (IP=[::]:636)
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 TLS established 
tls_ssf=256 ssf=256
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND 
dn="uid=auth,ou=sys,dc=noa,dc=gr" method=128
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 BIND 
dn="uid=auth,ou=sys,dc=noa,dc=gr" mech=SIMPLE ssf=0

Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=0 RESULT tag=97 err=0 text=
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH 
base="ou=people,dc=noa,dc=gr" scope=2 deref=0 
filter="(&(&(objectClass=inetOrgPerson)(!(schacUserStatus=internal)))(|(mail=jackie@noa.g

r)))"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SRCH attr=cn sn 
givenname title mail telephonenumber o ou;lang-en-us objectClass
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 ENTRY 
dn="uid=jackie,ou=people,dc=noa,dc=gr"
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=1 SEARCH RESULT tag=101 
err=0 nentries=1 text=

Oct 21 17:28:55 ldap slapd[18532]: conn=1317 op=2 UNBIND
Oct 21 17:28:55 ldap slapd[18532]: conn=1317 fd=19 close
...
Oct 21 17:31:54 ldap slapd[18532]: conn=1347 fd=19 ACCEPT from 
IP=[2001:648:2011:::]:35456 (IP=[::]:389)
Oct 21 17:31:54

Problem with SSL/TLS

2010-04-12 Thread Lynn York 
I have created a cert. on the server and openldap starts without any issues,
however when I attempt to connect via ldaps I keep getting the following
error:





ldapsearch -x -H ldaps://localhost:636 -D cn=Manager,dc=testing,dc=com -W
-b dc=testing,dc=com (objectClass=top)

Enter LDAP Password:

ldap_bind: Can't contact LDAP server (-1)

additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed



I can’t quite pin point what the problem might be.



Lynn York II

MavenWire Hosting Admin

www.mavenwire.com

(866) 343-4870 x717



MavenWire - We DELIVER

http://www.mavenwire.com



This e-mail and any attached files may contain confidential and/or
privileged material for the sole use of the intended recipient.  Any review,
use, distribution or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive this e-mail for the
recipient), you may not review, copy or distribute this message.  Please
contact the sender by reply e-mail and delete all copies of this message.

MavenWire - We DELIVER
http://www.mavenwire.com

This e-mail and any attached files may contain confidential and/or privileged 
material for the sole use of the intended recipient.  Any review, use, 
distribution or disclosure by others is strictly prohibited. If you are not the 
intended recipient (or authorized to receive this e-mail for the recipient), 
you may not review, copy or distribute this message.  Please contact the sender 
by reply e-mail and delete all copies of this message.

Re: Problem with SSL/TLS

2010-04-12 Thread Chris Jacobs 
/etc/ldap.conf is used by nss tools and the ilk.

/etc/openldap/ldap.conf would be used by openldap tools - like ldapsearch.

I have the same setting there for tls_checkpeer - but in the latter ldap.conf 
(under openldap).

FWIW: there's apparently no real different format for the two files; while one 
would only be setup on ldap servers, mine are identical and things work with a 
mirror master, both setup behind a VIP (fail over, not load balanced) and a 
plethora of slaves in different subdomains.

- chris

PS: I'd forgotten to 'reply-to-all' earlier. :)

Chris Jacobs, Systems Administrator
Apollo Group | Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
email: chris.jac...@apollogrp.edu


From: Lynn York
To: Chris Jacobs
Sent: Mon Apr 12 10:29:19 2010
Subject: RE: Problem with SSL/TLS
Here is my /etc/ldap.conf:

#host 127.0.0.1
base cn=users,dc=testing,dc=com
uri ldap://localhost:636
binddn cn=manager,dc=testing,dc=com
bindpw password
scope sub
timelimit 120
bind_policy soft
bind_timelimit 120
idle_timelimit 3600
ssl on
tls_cacert /etc/openldap/cacerts/servercrt.pem
tls_cacertdir /etc/openldap/cacerts
tls_checkpeer no
nss_base_group  cn=groups,dc=testing,dc=com?sub
pam_password md5

I have tried it with and without “tls_checkpeer”….   I am sort of at a loss as 
to what it can be.  I also tested it using openssl  client.. and here is the 
output:

CONNECTED(0003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=US/ST=Pennsylvania/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
verify return:1
depth=0 /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write certificate verify A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
   i:/C=US/ST=Pennsylvania/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
-BEGIN CERTIFICATE-
MIIDPzCCAqigAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx
FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx
EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq
hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x
MDA0MDkyMDUwNDlaFw0xMTA0MDkyMDUwNDlaMIGzMQswCQYDVQQGEwJVUzEVMBMG
A1UECBMMUGVubnN5bHZhbmlhMRgwFgYDVQQHEw9LaW5nIG9mIFBydXNzaWExFzAV
BgNVBAoTDk1hdmVuV2lyZSwgTExDMRAwDgYDVQQLEwdTdXBwb3J0MRYwFAYDVQQD
Ew1tYXZlbndpcmUuY29tMTAwLgYJKoZIhvcNAQkBFiFtdy1ob3N0aW5nLXN5c2Fk
bWluQG1hdmVud2lyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMGp
U5HS8A2DRokU5TQz1Dyycx/VA2uhrRwatTPq8xtoQigWM2feiXUwtoiQ/gP3IjB5
AJLf8aC8y72Io2IME4aqh1s7bdscV2b0QMs1MfXiL9h2XQWZVCkgDLjjb1XzHhlw
3I6vkrh/uGH2PQyXbuG/6dIguzCHfnGgGXgy1o45AgMBAAGjezB5MAkGA1UdEwQC
MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl
MB0GA1UdDgQWBBR0mZkOwZZjYFiWlloEvgSpoPxOuzAfBgNVHSMEGDAWgBS7Iqbt
j25p56k4BdHpXYG3xjhdijANBgkqhkiG9w0BAQUFAAOBgQARO7OcDgNOZ3WuP9IM
mUeQWuGVBAh7MQ3Uv2HrSOAfTHxg/QxjCZZlwULq1EZZDHNgyPMM+5ElWSID5El/
fdxHcizNOjPPuVPwtJIrs8RhTIehn0aKryqtkvpcAnxFuc+VxwcCBhV58wtbSuXL
PXRTvoTDXWkiXwdR4m1bubOF5A==
-END CERTIFICATE-
 1 s:/C=US/ST=Pennsylvania/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
   i:/C=US/ST=Pennsylvania/O=MavenWire, 
LLC/OU=Support/CN=testing.com/emailaddress=test...@testing.comhttp://testing.com/emailaddress=test...@testing.com
-BEGIN CERTIFICATE-
MIIDJTCCAo6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx
FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx
EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq
hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x
MDA0MDkyMDUwMDBaFw0xMzA0MDgyMDUwMDBaMIGZMQswCQYDVQQGEwJVUzEVMBMG
A1UECBMMUGVubnN5bHZhbmlhMRcwFQYDVQQKEw5NYXZlbldpcmUsIExMQzEQMA4G
A1UECxMHU3VwcG9ydDEWMBQGA1UEAxMNbWF2ZW53aXJlLmNvbTEwMC4GCSqGSIb3
DQEJARYhbXctaG9zdGluZy1zeXNhZG1pbkBtYXZlbndpcmUuY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC6yVPz1ccamBapkRR8vTjpiKj7JuJKdCecTQ7/
f2KWoIRuYdEWU4njEsu/KHQWmxR0lelqOzM15EHVanOJCsPKCEMQg4lY5cQm8W1Q

Re: Problem with SSL/TLS

2010-04-12 Thread Howard Chu 

Chris Jacobs wrote:

/etc/ldap.conf is used by nss tools and the ilk.

/etc/openldap/ldap.conf would be used by openldap tools - like ldapsearch.


Actually it's used by libldap, which means everything that uses libldap 
(including nss_ldap). But of course the converse is not true, /etc/ldap.conf 
only affects nss_ldap and pam_ldap, not anything else.



I have the same setting there for tls_checkpeer - but in the latter ldap.conf
(under openldap).


tls_checkpeer is not a valid OpenLDAP ldap.conf keyword.


FWIW: there's apparently no real different format for the two files; while one
would only be setup on ldap servers, mine are identical and things work with a


If they are identical and things work, it's by sheer luck. Read the 
ldap.conf(5) manpage. Relying on anything not documented there would be a mistake.


To the original poster: use the ldapsearch debug flag. OpenSSL s_client is not 
a reliable indicator of anything.



mirror master, both setup behind a VIP (fail over, not load balanced) and a
plethora of slaves in different subdomains.

- chris

PS: I'd forgotten to 'reply-to-all' earlier. :)

Chris Jacobs, Systems Administrator
Apollo Group | Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661
email: chris.jac...@apollogrp.edu

--
*From*: Lynn York
*To*: Chris Jacobs
*Sent*: Mon Apr 12 10:29:19 2010
*Subject*: RE: Problem with SSL/TLS

Here is my /etc/ldap.conf:

#host 127.0.0.1

base cn=users,dc=testing,dc=com

uri ldap://localhost:636

binddn cn=manager,dc=testing,dc=com

bindpw password

scope sub

timelimit 120

bind_policy soft

bind_timelimit 120

idle_timelimit 3600

ssl on

tls_cacert /etc/openldap/cacerts/servercrt.pem

tls_cacertdir /etc/openldap/cacerts

tls_checkpeer no

nss_base_group cn=groups,dc=testing,dc=com?sub

pam_password md5

I have tried it with and without “tls_checkpeer”…. I am sort of at a loss as
to what it can be. I also tested it using openssl client.. and here is the 
output:



*From*: openldap-technical-bounces+chris.jacobs=apollogrp.edu
http://apollogrp.edu@OpenLDAP.org
*To*: openldap-technical@openldap.org mailto:openldap-technical@openldap.org
*Sent*: Mon Apr 12 08:13:39 2010
*Subject*: Problem with SSL/TLS

I have created a cert. on the server and openldap starts without any issues,
however when I attempt to connect via ldaps I keep getting the following error:

??

??

ldapsearch -x -H ldaps://localhost:636 -D cn=Manager,dc=testing,dc=com -W -b
dc=testing,dc=com (objectClass=top)

Enter LDAP Password:

ldap_bind: Can't contact LDAP server (-1)

?? additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

??

I can???t quite pin point what the problem might be.??



--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Problem with SSL/TLS

2010-04-12 Thread Siddhartha Jain 
I ran into various issues with OpenLDAP + SSL/TLS. Finally, I ended up 
tunneling via stunnel. Something you might want to consider?


Siddhartha




From: openldap-technical-bounces+sjain=silverspringnet@openldap.org 
[mailto:openldap-technical-bounces+sjain=silverspringnet@openldap.org] On 
Behalf Of Lynn York
Sent: Monday, April 12, 2010 8:14 AM
To: openldap-technical@openldap.org
Subject: Problem with SSL/TLS

I have created a cert. on the server and openldap starts without any issues, 
however when I attempt to connect via ldaps I keep getting the following error:


ldapsearch -x -H ldaps://localhost:636 -D cn=Manager,dc=testing,dc=com -W -b 
dc=testing,dc=com (objectClass=top)
Enter LDAP Password:
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I can't quite pin point what the problem might be.

Lynn York II
MavenWire Hosting Admin
www.mavenwire.comhttp://www.mavenwire.com
(866) 343-4870 x717

MavenWire - We DELIVER
http://www.mavenwire.com

This e-mail and any attached files may contain confidential and/or privileged 
material for the sole use of the intended recipient.  Any review, use, 
distribution or disclosure by others is strictly prohibited. If you are not the 
intended recipient (or authorized to receive this e-mail for the recipient), 
you may not review, copy or distribute this message.  Please contact the sender 
by reply e-mail and delete all copies of this message.


MavenWire - We DELIVER

http://www.mavenwire.com



This e-mail and any attached files may contain confidential and/or privileged 
material for the sole use of the intended recipient.  Any review, use, 
distribution or disclosure by others is strictly prohibited. If you are not the 
intended recipient (or authorized to receive this e-mail for the recipient), 
you may not review, copy or distribute this message.  Please contact the sender 
by reply e-mail and delete all copies of this message.

RE: Problem with SSL/TLS

2010-04-12 Thread Lynn York 
As that might be a viable option, at this point it is not.  I have too many
servers that will be getting the user information from LDAP, I would much
rather just copy a couple certs instead of installing stunnel..  unless, I
am missing something here?



*From:* Siddhartha Jain [mailto:sj...@silverspringnet.com]
*Sent:* Monday, April 12, 2010 3:53 PM
*To:* Lynn York; openldap-technical@openldap.org
*Subject:* RE: Problem with SSL/TLS



I ran into various issues with OpenLDAP + SSL/TLS. Finally, I ended up
tunneling via stunnel. Something you might want to consider?





Siddhartha









*From:* 
openldap-technical-bounces+sjain=silverspringnet@openldap.org[mailto:
openldap-technical-bounces+sjain openldap-technical-bounces%2Bsjain=
silverspringnet@openldap.org] *On Behalf Of *Lynn York
*Sent:* Monday, April 12, 2010 8:14 AM
*To:* openldap-technical@openldap.org
*Subject:* Problem with SSL/TLS



I have created a cert. on the server and openldap starts without any issues,
however when I attempt to connect via ldaps I keep getting the following
error:





ldapsearch -x -H ldaps://localhost:636 -D cn=Manager,dc=testing,dc=com -W
-b dc=testing,dc=com (objectClass=top)

Enter LDAP Password:

ldap_bind: Can't contact LDAP server (-1)

additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed



I can’t quite pin point what the problem might be.



Lynn York II

MavenWire Hosting Admin

www.mavenwire.com

(866) 343-4870 x717



MavenWire - We DELIVER

http://www.mavenwire.com



This e-mail and any attached files may contain confidential and/or
privileged material for the sole use of the intended recipient.  Any review,
use, distribution or disclosure by others is strictly prohibited. If you are
not the intended recipient (or authorized to receive this e-mail for the
recipient), you may not review, copy or distribute this message.  Please
contact the sender by reply e-mail and delete all copies of this message.



MavenWire - We DELIVER

http://www.mavenwire.com



This e-mail and any attached files may contain confidential and/or
privileged material for the sole use of the intended recipient.  Any
review, use, distribution or disclosure by others is strictly
prohibited. If you are not the intended recipient (or authorized to
receive this e-mail for the recipient), you may not review, copy or
distribute this message.  Please contact the sender by reply e-mail
and delete all copies of this message.

MavenWire - We DELIVER
http://www.mavenwire.com

This e-mail and any attached files may contain confidential and/or privileged 
material for the sole use of the intended recipient.  Any review, use, 
distribution or disclosure by others is strictly prohibited. If you are not the 
intended recipient (or authorized to receive this e-mail for the recipient), 
you may not review, copy or distribute this message.  Please contact the sender 
by reply e-mail and delete all copies of this message.

RE: Problem with SSL/TLS

2010-04-12 Thread Quanah Gibson-Mount 
--On Monday, April 12, 2010 2:20 PM -0400 Lynn York 
lynn.y...@mavenwire.com wrote:



TLS certificate verification: depth: 0, err: 18, subject:
/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire,
LLC/OU=Support/CN=testing.com/emailaddress=mw-hosting-sysad...@testing.co
m, issuer: /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire,
LLC/OU=Support/CN=testing.com/emailaddress=mw-hosting-sysad...@testing.com
TLS certificate verification: Error, self signed certificate
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B



The above error seems very clear to me.  The CA for the offered cert is 
unknown.  Either your CA path for OpenLDAP is wrong in your OpenLDAP 
ldap.conf file (which is set via the TLS_CACERT or TLS_CACERTDIR 
variables), or you've pointed at the wrong one, etc.


As has been noted numerous times to you so far /etc/ldap.conf is not the 
place you set these variables. You fail to show your /etc/ldap/ldap.conf 
(assuming that's the location of it) settings.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

RE: Problem with SSL/TLS

2010-04-12 Thread Lynn York 
Here is my /etc/openldap/ldap.conf:

uri ldaps://localhost
base cn=users,dc=testing,dc=com
tls_cacert /etc/openldap/cacerts/ca.key
tls_cacertdir /etc/openldap/cacerts
tls_reqcert allow


After adding the TLS options in there, I get the following:

ldapsearch -d1 -x -H ldaps://localhost:636/
ldap_create
ldap_url_parse_ext(ldaps://localhost:636/)
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_connect_timeout: fd: 3 tm: -1 async: 0
TLS: could not load verify locations
(file:`/etc/openldap/cacerts/ca.key',dir:`/etc/openldap/cacerts').
ldap_perror
ldap_bind: Can't contact LDAP server (-1)



However, the certs and key's to exist..

ls -al /etc/openldap/cacerts/
total 44
drwxr-xr-x 3 ldap ldap 4096 Apr 12 13:48 .
drwxr-xr-x 4 ldap ldap 4096 Apr 12 18:09 ..
drwxr-xr-x 2 ldap ldap 4096 Apr 12 13:45 backup
-rw-r--r-- 1 ldap ldap 1805 Apr 12 13:46 ca.cert
-rw-r--r-- 1 ldap ldap 1679 Apr 12 13:46 ca.key
-rw-r--r-- 1 ldap ldap   17 Apr 12 13:48 ca.srl
-rw-r--r-- 1 ldap ldap 1411 Apr 12 13:48 hltraindb01.crt
-rw-r--r-- 1 ldap ldap 1106 Apr 12 13:46 hltraindb01.csr
-rw-r--r-- 1 ldap ldap 1679 Apr 12 13:45 hltraindb01.key


-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@zimbra.com]
Sent: Monday, April 12, 2010 6:00 PM
To: Lynn York
Cc: openldap-technical@openldap.org
Subject: RE: Problem with SSL/TLS

--On Monday, April 12, 2010 2:20 PM -0400 Lynn York
lynn.y...@mavenwire.com wrote:

 TLS certificate verification: depth: 0, err: 18, subject:
 /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire,

LLC/OU=Support/CN=testing.com/emailaddress=mw-hosting-sysad...@testing.co
 m, issuer: /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire,

LLC/OU=Support/CN=testing.com/emailaddress=mw-hosting-sysad...@testing.com
 TLS certificate verification: Error, self signed certificate
 TLS trace: SSL3 alert write:fatal:unknown CA
 TLS trace: SSL_connect:error in SSLv3 read server certificate B
 TLS trace: SSL_connect:error in SSLv3 read server certificate B


The above error seems very clear to me.  The CA for the offered cert is
unknown.  Either your CA path for OpenLDAP is wrong in your OpenLDAP
ldap.conf file (which is set via the TLS_CACERT or TLS_CACERTDIR
variables), or you've pointed at the wrong one, etc.

As has been noted numerous times to you so far /etc/ldap.conf is not the
place you set these variables. You fail to show your /etc/ldap/ldap.conf
(assuming that's the location of it) settings.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration
MavenWire - We DELIVER
http://www.mavenwire.com

This e-mail and any attached files may contain confidential and/or privileged 
material for the sole use of the intended recipient.  Any review, use, 
distribution or disclosure by others is strictly prohibited. If you are not the 
intended recipient (or authorized to receive this e-mail for the recipient), 
you may not review, copy or distribute this message.  Please contact the sender 
by reply e-mail and delete all copies of this message.

RE: Problem with SSL/TLS

2010-04-12 Thread Quanah Gibson-Mount 
--On Monday, April 12, 2010 6:13 PM -0400 Lynn York 
lynn.y...@mavenwire.com wrote:



Here is my /etc/openldap/ldap.conf:

uri ldaps://localhost
base cn=users,dc=testing,dc=com
tls_cacert /etc/openldap/cacerts/ca.key
tls_cacertdir /etc/openldap/cacerts
tls_reqcert allow


You specify *one* of the two options (Either TLS_CACERT or TLS_CACERTDIR). 
Not both.  If you are specifying the file, then it needs to be the cert, 
not the key.




TLS: could not load verify locations
(file:`/etc/openldap/cacerts/ca.key',dir:`/etc/openldap/cacerts').



However, the certs and key's to exist..

ls -al /etc/openldap/cacerts/
total 44
drwxr-xr-x 3 ldap ldap 4096 Apr 12 13:48 .
drwxr-xr-x 4 ldap ldap 4096 Apr 12 18:09 ..
drwxr-xr-x 2 ldap ldap 4096 Apr 12 13:45 backup
-rw-r--r-- 1 ldap ldap 1805 Apr 12 13:46 ca.cert
-rw-r--r-- 1 ldap ldap 1679 Apr 12 13:46 ca.key


What about the permissions on /etc/openldap and /etc/openldap/cacerts?

I.e., if you su - ldap, can you actually read /etc/openldap/cacerts/ca.cert?

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration