Search results for "starttls" - openldap-technical

TLS hostname check failure and subjectAltname extension

by Michael Ströder

HI! We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked against OpenSSL 1.0.0 libs shipped with RHEL. (some names are consistently obfuscated herein to keep real names confidential) Unfortunately we can't get StartTLS to work. It always fails: # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate # /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate But OpenSSL lists the (IMO correct) hostnames in the server's certificate: ---------------------------------- snip ---------------------------------- Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE [..] X509v3 Subject Alternative Name: email:certificate@xxx.domain, DNS:ldap.domain, DNS:ldap-srv01.rz.domain, DNS:ldap-srv02.rz.domain ---------------------------------- snip ---------------------------------- Is the hostname check confused by the email in the first subjectAltName sequence value? Ciao, Michael.

13 years, 5 months

Re: LDAP and SSL

by Dan White

On 26/09/11 10:18 -0400, criderkevin(a)aol.com wrote: > >I'm struggling with the need for SSL... > >We will use our new LDAP for apps. These servers are all locally housed so >each app server will talk to the LDAP server over our network. (why) Would >we need SSL? > >What about for mail services? It seems to me that our mail server would >also talk directly to the LDAP server...what am I missing here that >dictates the use of SSL with LDAP? I could see if one had their LDAP open >to be accessible direct access from off-network. Perhaps SSL is used >simply as a means to authenitcate? If you're performing TLS authentication, using client certificates, via STARTTLS, then using X.509 provides for a strong authentication mechanism using SASL (EXTERNAL). That's the one benefit that I know of beyond the obvious session based encryption that you obtain using certificates. -- Dan White

13 years, 8 months

Re: syncrepl mirrormode with SSL/TLS issues

by Quanah Gibson-Mount

--On Wednesday, January 09, 2013 6:19 PM -0600 Houston Ray <houston.r.hopkins(a)gmail.com> wrote: > > > I am attempting to move my sycrepl with mirrormode configuration over to > TLS using LDAPS (not starttls) and running into problems. > > > Multimaster setup (2 servers) behind a VIP > > both RHEL 6.3 Problem 1 > Openldap 2.4.23-26 Problem 2 Don't use RH's builds of OpenLDAP, they link to their broken MozNSS stuff. Use a current release of OpenLDAP. Once you've done that, then see what progress you can make. I would note you can get useful OpenLDAP builds for RHEL from <http://ltb-project.org/wiki/download#openldap> They link to OpenSSL rather than MozNSS, and are current. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 5 months

Re: TLS, integrity and root DSE

by Quanah Gibson-Mount

--On Wednesday, July 24, 2013 4:08 PM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Hi! > > When trying to require integrity for LDAP connections by specifying > "ssf=1" in Security, I have a problem with Perl where the cat bites its > tail: > > It's recommended to query the root DSE for TLS extension before trying to > use TLS like this: > > my $dse = $ldap->root_dse(); > > if ($dse->supported_extension(LDAP_EXTENSION_START_TLS)) { > my $msg = $ldap->start_tls('verify' => 'require', > 'capath' => '/etc/ssl/certs'); > ... Personally, I just always try to startTLS regardless. Then you can decide whether or not you wish to continue after that point based on whether or not it succeeds or fails. --Quanha -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 10 months

Re: Openldap server with TLS not working

by Michael Ströder

btb wrote: > On 2013.10.02 07.29, Axel Grosse wrote: > >> when I test on the server itself .. >> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >> ./ssl/VordelCA.crt >> CONNECTED(00000003) >> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >> failure:s23_lib.c:188: > > ldaps [port 636] is deprecated. > use starttls with the standard port [389]. > to test, just use ldapsearch [see the reference to -Z in the man page] This is nonsense. From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS. I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share. Ciao, Michael.

11 years, 8 months

Re: ldapi and StartTLS

by Richard Gray

On 2018-07-12 06:52, Norman Gray wrote: > What am I misunderstanding? > > In the slapd.ldif I have: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/openldap/slapd.args > olcPidFile: /var/run/openldap/slapd.pid > olcSecurity: ssf=128 > olcTLSCertificateFile: /usr/local/etc/openldap/certs/XXX.crt > olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/XXX.key > olcTLSCACertificateFile: /usr/local/etc/openldap/certs/FOO > olcLogLevel: 0 Have a look at 'olcLocalSSF' in slapd-config(5), which lets you set the security strength factor for local (i.e. ldapi://) sessions. It defaults to 71, which is likely why you're seeing that error message. Personally, I bump it up to 256, to match the ssf=256 I have set in the olcSecurity attribute on cn=config. -- Richard Gray _____________________________________________________________________________ This email has been filtered by SMX. For more info visit http://smxemail.com _____________________________________________________________________________

6 years, 11 months

Re: OpenLDAP self-signed certificates issue

by Michael Ströder

Ryan Tandy wrote: > On 07/09/14 10:28 PM, Vijay Ganesan wrote: >> But I can't seem to connect using ldaps://localhost:636 using Apache >> Directory Studio client. I get a "Error while opening connection - >> Cannot connect on the server: Connection refused" error. >> I can connect fine using ldap://localhost:389. > > Like Udai wrote, ldaps is deprecated, and if possible you should use > STARTTLS on the LDAP port (389) instead. LDAPS on separate port was not formally defined in a RFC. But there's nothing wrong using it. Personally I even prefer LDAPS since you can then make sure that the client has to establish a TLS connection before sending any LDAP PDU. > But if you really need ldaps, then edit > /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line, and restart slapd. Yes. Ciao, Michael.

10 years, 9 months

Re: Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Dieter Kluenter

Hi, Jörg Spilker <js(a)jetsys.de> writes: > Hi, > > well, i don´t know what i´m doing wrong. I just want to authenticate > unix and windows users against OpenLDAP Database. I followed some howtos > to setup openldap, winbind etc. and nearly everything seems just fine. > But authenticating unix users finally doesn´t work. I´ve attached the > syslog output. START TLS extension not supportet. This is true, as i > haven´t configured OpenLPAP for TLS. But my LDAP client configuration > doesn´t specify an LDAPS URL. So what´s going wrong? Some Linux distributions have enabled 'ssl start_tls' as default, please check your /etc/ldap.conf carefully. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

16 years, 11 months

Re: ldaprc with ldaps:// and ldap:// fallback

by Dieter Kluenter

manu(a)netbsd.org (Emmanuel Dreyfus) writes: > Hello > > I would like to setup a ldaprc so that an application uses: > - a localhost-base slapd without authentification (just relying on > filesystem permission on the slapd socket) > - if it is not available, a remote slapd, authenticating using client > certificate > > Here is the desired ldaprc: > BASE dc=example,dc=net > URI ldapi:/// ldaps://ldap.example.net > TLS_CACERT /etc/openssl/ca.crt > TLS_CERT /etc/openssl/host.crt > TLS_KEY /etc/openssl/host.key > SASL_MECH EXTERNAL > TLS_REQCERT demand > > Of course it will not work, as the ldapi:/// connection will present a > certificate. I have the feeling the setup I am looking for cannot be > configured. Is that right? No, ldapi:/// doesn't present a certificate, but you may establish a startTLS session to ldapi:///, in this case the client requests a server certificate. -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

14 years, 11 months

Re: new entry lost on multi-master setup (two scenarios)

by Jose Ildefonso Camargo Tolosa

Greetings, Any comments on this? can anybody help me verify this possible bug? Ildefonso. On Sun, Apr 17, 2011 at 2:24 PM, Jose Ildefonso Camargo Tolosa <ildefonso.camargo(a)gmail.com> wrote: > Greetings, > > At first, I was going to create a bug report, but decided to send to > list first. I tried this with both: 2.4.23 (Debian package), and > 2.4.25, compiled from source, bdb 4.8. > > After a couple of entries just disappeared on one multi-master setup I > had, I decided to further investigate, and found this (there are two > cases, for the same procedure): > > 1. Configure two LDAP servers in multi-master setup. > 2. Make sure they replicate correctly (off course). > 3. Shutdown one of the two ldap servers. > 4. Create a new entry (say, ou1) on the LDAP server that is left up. > 5. Shutdown the last LDAP server. > 6. Start the *other* LDAP server, the one where you didn't create the entry. > 7. Create another entry, say: ou2, so that both servers has a new > entry, that is *not* on the other server. > 8. Shutdown the LDAP server (both servers down now). > 9. Start both LDAP servers. > > Result (case 1): one of the two newly created entries is missing on > *one* of the servers, and only one of the entries is missing on the > other server. > > Result (case 2): one entry is missing on *both* servers. > > Both servers has NTP, and has the same timezone (ie, time is synchronized). > > I'm *not* replicating cn=config (I shouldn't, because I have different > SSL certificates on each server). Now, more details: > > slapd with -d 16384 gives me this on the server that misses both > entries, on this server I created the entry dn > ou=ou2,dc=st-andes,dc=com (and the server decided to delete it!, and, > for some reason, it didn't detected the new ou1 entry created on the > other server): > > http://www.st-andes.com/openldap/case1/log-server2-case1.txt > > The other server (the one that kept one entry and lost the other), on > this server I created the entry ou=ou1,dc=st-andes,dc=com, and it says > it was changed by peer.....: > > http://www.st-andes.com/openldap/case1/log-server1-case1.txt > > Now, I'm seeing here that it is using 000 server id... but on the > cn=config.ldif I have: > > olcServerID: 1 ldap://ldap.ildetech.com:389/ > olcServerID: 2 ldap://ldap2.ildetech.com:389/ > > And the syncrepl: > > olcSyncRepl: rid=001 provider=ldap://ldap.ildetech.com:389 > binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple > credentials="secret" searchbase="dc=st-andes,dc=com" > type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical > olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 > binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple > credentials="secret" searchbase="dc=st-andes,dc=com" > type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical > olcMirrorMode: TRUE > > And, as you can see on the command line, I have the URL specified on > the -h parameter, but it seems to be ignoring it!. Or, should I > specify the *whole* urls that I put on the -h parameter? > (ldap://ldap2.ildetech.com:389 ldap://127.0.0.1:389/ ldaps:/// > ldapi:///) > > So, I decided to change the config: > > On server 1 (kirara): > > olcServerID: 1 > > and > > olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 > binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple > credentials="secret" searchbase="dc=st-andes,dc=com" > type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical > olcMirrorMode: TRUE > > On server 2 (happy): > > olcServerID: 2 > > and > > olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 > binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple > credentials="secret" searchbase="dc=st-andes,dc=com" > type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical > olcMirrorMode: TRUE > > With this new setup, and following the same procedure, I get one > missing entry on *both* servers (at least servers gets to a consistent > state), but I still have a missing entry. The logs for this setup: > > Server 2 (ID 2, where I created entry: ou2 while the other server was > down), this server decided, wrongly, to delete entry ou2: > > http://www.st-andes.com/openldap/case2/log-server2-case2.txt > > And the other server (where I created ou1): > > http://www.st-andes.com/openldap/case2/log-server1-case2.txt > > This one never saw the other entry, ou2. > > For both cases, the syncprov module was with default configuration: > > dn: olcOverlay={0}syncprov > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: {0}syncprov > structuralObjectClass: olcSyncProvConfig > entryUUID: 24354488-e5bf-102f-9e6a-ad3cba95f7f1 > creatorsName: cn=config > createTimestamp: 20110318152128Z > entryCSN: 20110318152128.935227Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20110318152128Z > > What do you think? > > Thanks in advance! > > Ildefonso Camargo >

14 years, 1 month

openldap-technical search results for query "starttls"