Replace old secure with new secure

[robe]

Right now LDAP server ldaps://ldap.osgeo.org is using the star cert which is about to expire as running

openssl s_client -connect ldap.osgeo.org:636

confirms. This will expire 5/1/2019 so needs to be replace.

[robe]

I went ahead and got a letsencrypt wildcard cert for osgeo using the command on nginx container

certbot certonly --manual --preferred-challenges=dns -d *.osgeo.org

I had to put in a TXT record in osgeo DNS Pair for this

Which gave me a -

- Congratulations! Your certificate and chain have been saved at:
  /etc/letsencrypt/live/osgeo.org/fullchain.pem
  Your key file has been saved at:
  /etc/letsencrypt/live/osgeo.org/privkey.pem
  Your cert will expire on 2019-07-25. To obtain a new or tweaked
  version of this certificate in the future, simply run certbot
  again. To non-interactively renew *all* of your certificates, run
  "certbot renew"
- If you like Certbot, please consider supporting our work by:

  Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
  Donating to EFF:                    https://eff.org/donate-le

and then copied the generated files to secure /etc/ssls/certs/osgeo.org

I was hoping I could just edit the slapd.conf restart the slapd service, as is documented in the wiki - ​https://wiki.osgeo.org/wiki/SAC:LDAP

But it appears the wiki is out of date, and we no longer use the slapd.conf and have switched to OLC. Which is in /etc/ldap/slapd.d/ - cp=config.ldif file

I read I should edit this using ldapmodify or ldapbrowser. I'm hesitant to go any further lest I screw things up.

[robe]

I got as far as creating an ssl.ldif that has this in it:

dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile:  /etc/ssl/certs/osgeo.org/privkey.pem
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/osgeo.org/chain.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile:  /etc/ssl/certs/osgeo.org/cert.pem

And then trying to install with this (note I'm doing this on replica of secure, not on secure directly yet)

SLAPD_SERVICES="ldaps://ldap.osgeo.org"
ldapmodify  -W -D "cn=Manager,dc=osgeo,dc=org" -H ldaps://ldap.osgeo.org -f ssl.ldif

and it prompted me with a password which I found in the root/access list for phpldap.

But I got this error:

modifying entry "cn=config" ldap_modify: Insufficient access (50)

If I type in the wrong password I do get a invalid password, so I have the right password for this account, but this one appears to not have enough privilege to edit the configs

[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 and I documented my steps in the gitea/sac/osgeo7/wiki. I also restored the old ldap users database, but not the config. config I rebuilt from scratch since trying to use the old I couldn't do an ldapmodify.

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

[robe]

Tested on funtoo.osgeo.org and that one works too.

I tried on winnie.postgis.net and it worked with ldap.osgeo.org and not ldap2.osgeo.org

If I edit /etc/ldap/ldap.conf

Taking out the old star cert and replacing with the packaged certificate bundle, then it works on her too.

#TLS_CACERT /etc/ssl/certs/STAR_osgeo_org.ca-bundle  #this file you need to copy from osgeo6 as well
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt

I guess with the newer servers I had set up , I never bothered changing the default TLS_CACERT since it seemed to work without the change so that might be why all the newer ones I setup work.

I just tried on old-adhoc and works too if I change the TLS_CACERT entry. There is a similar change I think I need to make possibly in the nss files for login will test that next.

[robe]

okay on old-adhoc (and I'm guessing I got to fix all the servers even the new ones I created (as this was in my setup template). I had to do a similar change in /etc/nslcd.conf

as it hadth ssl.com star certbundle instead of the shipped cert file

#tls_cacertfile /etc/ssl/certs/STAR_osgeo_org.ca-bundle
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

Changing the file is not sufficient. The services need to be restarted - though I ended just rebooting the container, so have to outline which services need restarting.

[robe]

Changing ticket title since I plan to swap out old secure.osgeo.osuosl.org with new secure after I have remigrated the ldap user database.

[robe]

Looks like doing

service nslcd restart  #LDAP connection daemon

Is sufficient to allow login access using new ssh key (after /etc/nslcd.conf is changed to use the OS packaged cert bundle)

[robe]

Okay I hope i didn't miss any. I had to change the following servers to use the OS included cert bundle (needed for cert root authentication) and told jef to change the QGIS ones in same fashion. Without this change we can never use anything but the SSL.com cert. The OS packaged bundle works for both the existing SSL.com cert (expiring May 1) and the new Letsencrypt cert.

Change was as follows: on /etc/ldap/ldap.conf

#TLS_CACERT /etc/ssl/certs/STAR_osgeo_org.ca-bundle  #this file you need to copy from osgeo6 as well
TLS_CACERT  /etc/ssl/certs/ca-certificates.crt

on /etc/nslcd.conf

#tls_cacertfile /etc/ssl/certs/STAR_osgeo_org.ca-bundle
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

followed by

service nslcd restart

Done to:

all the containers on osgeo7 that use ldap
Servers -
adhoc.osgeo.osuosl.org (this has bee migrated but it's still on and need to check if anything left)
backup.osgeo.osuosl.org
download.osgeo.osuosl.org #note this will hopefully be defunct soon once I have webdav onnew container
osgeo6.osgeo.osuosl.org
projects.osgeo.osuosl.org #this sites now on old-projects on osgeo7, dut did this just in case mssed anything
tracsvn.osgeo.osuosl.org
webextra.osgeo.osuosl.org
web.osgeo.osuosl.org #most stuff already migrated  (and on old-web container)
wiki.osgeo.osuosl.org

[robe]

I have done a final migration of the user database and shut down the slapd on secure.osgeo.osuosl.org

I have brought up the new one with ip 140.211.15.57

I expect people to have log in issues until the changes propagate, but I'd rather that than the old database being written to.