We want to access the UCS LDAP(S) connection with an external service, but with a valid certificate. This example was created during the LDAPS-connection of WebUntis.
- Letsencrypt provides certificates which should be accepted by all external LDAP connections
- replacing the internally used LDAP certificates is a bad idea, things might break completely
- it’s possible to use a SSL proxy like nginx
- but we already have
Warning: the following port mapping works only without Samba/AD installed!
- the listening port has to be free & and opened in the Univention firewall
- e.g., if we use port 636, we check it:
ss -nltp | grep 636- inside
sudo nmap <hostname/Ip> -p 636- outside
- on my system, port 636 was in use by ldaps (but with the self-signed certificate), so I did
ucr set slapd/port/ldaps='7636'and left the firewall settings as is
- Letsencrypt certificates, the LetsEncrypt App is recommended.
If you use Samba/AD, port 636 shouldn’t be changed, I recommend to use port 8636 instead.
We are going to forward external, SSL encrypted LDAPS connections at port 636 (with Samba: 8636) to our locally running LDAP-Server at port 7389 (unencrypted) by using stunnel for SSL termination.
Put the following in
; stunnel configuration to allow WebUntis to access an ; officially signed certificate while OpenLDAP still operates ; with the self-signed certificate ; Global configuration ; Certificate/key is needed in server mode and optional in client mode cert = /etc/univention/letsencrypt/signed_chain.crt key = /etc/univention/letsencrypt/domain.key ; Some security enhancements for UNIX systems - comment them out on Win32 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 ; PID is created inside the chroot jail pid = /stunnel4.pid options = NO_SSLv3 ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Service-level configuration [ssl-proxy] accept = 636 connect = 7389
Now, do a
systemctl restart stunnel4.service and
To automate the restart of stunnel when the LetsEncrypt certificates get renewed, we do the following:
cat << EOF > /etc/univention/letsencrypt/post-refresh.d/stunnel #!/bin/bash systemctl restart stunnel4.service EOF chmod +x /etc/univention/letsencrypt/post-refresh.d/stunnel
The next time when a LetsEncrypt certifcate is renewed, stunnel gets restarted, too.
- verify the server certificate by
openssl s_client -connect <hostname>:636 -showcerts, should be Letsencrypt
- start your LDAP connection like before, but now with valid certificates