[SAC] [OSGeo] #2295: Replace ldaps STAR cert with letsencrypt or single cert

[OSGeo]

#2295: Replace ldaps STAR cert with letsencrypt or single cert
---------------------------+---------------------------------------
 Reporter:  robe           |       Owner:  sac@…
     Type:  task           |      Status:  new
 Priority:  blocker        |   Milestone:  Sysadmin Contract 2019-I
Component:  Systems Admin  |  Resolution:
 Keywords:                 |
---------------------------+---------------------------------------

Comment (by robe):

 I tried tricking the system by sym-linking the letsencrypt cert files to
 the old names.
 That did not work on the old-secure container so I didn't bother with the
 actual secure.

 Sooo I've moved on to plan D - which was the eventual direction of
 scraping the old ldap and replacing with a new LDAP.

 I have a container on osgeo7 called new-secure - which has 636 open to
 OSUOSL domain and LXD subdomain.  I'm going to transcribe the rest of the
 whitelists to it once I've troubleshooted some things and tested on some
 other things.

 The new ldap is running Debian 9 and using letsencrypt wildcard cert.
 Took a lot of fumbling to figure out how to get this working.  I also
 restored the old ldap users database, but not the config.  config I
 rebuilt from scratch.

 I tested accessing it from web18a.osuosl.org VM (which is fairly new), the
 nextcloud container (swapping out old ldap with new ldap) and both worked:

 Here is a test

 {{{
 ldapsearch -x "uid=robe" -b "dc=osgeo,dc=org"  -H ldaps://ldap2.osgeo.org
 }}}


 Which shows my details.

 However this did not work on current secure or osgeo6 (I assume it will be
 an issue with all our old servers) -- I think just missing an intermediary
 cert for le, because when I run:


 {{{
 ldapsearch -d1 -x "uid=robe" -b "dc=osgeo,dc=org"  -H
 ldaps://ldap2.osgeo.org #d1 for debug details
 }}}

 on secure gives this:


 {{{
 TLS: peer cert untrusted or revoked (0x42)
 TLS: can't connect: (unknown error code).
 ldap_err2string
 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 }}}



 If I swap out the letsencrypt on ldap2 with the old ssl, secure can query
 it. So it's definitely the cert and not any firewall issue.

 I was disappointed this did not work out of the box on osgeo6 and gave the
 same notice


 {{{
 ldap_connect_to_host: Trying 140.211.15.57:636
 ldap_pvt_connect: fd: 4 tm: -1 async: 0
 attempting to connect:
 connect success
 TLS: peer cert untrusted or revoked (0x42)
 TLS: can't connect: (unknown error code).
 ldap_err2string
 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 }}}

 But it could be we've been copying the cert authorities across all the
 servers and they are just missing the newer ones.

 Anyway hoping it's simple as just copying newer certs as this describes:

 https://serverfault.com/questions/579131/some-systems-cannot-connect-to-
 ldap-via-ldaps-but-others-can-is-it-the-wildcar/579148

-- 
Ticket URL: <https://trac.osgeo.org/osgeo/ticket/2295#comment:3>
OSGeo <https://osgeo.org/>
OSGeo committee and general foundation issue tracker.