Problem
AD-Connector fails to sync with a traceback in /var/log/univention/connector-ad-status.log that ends in
ldap.CONNECT_ERROR: {'desc': 'Connect error', 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (EE certificate key too weak)'}
Or e.g. it ends with
ldap.CONNECT_ERROR: {'desc': 'Connect error', 'info': 'error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol'}
Solution
As noted in the Release Notes for UCS 5.0-0 Debian raised the minimal accepted quality of SSL certificates. This can be controlled via the file /etc/ssl/openssl.cnf. The interesting section is
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
which is explained in https://ubuntu.com/server/docs/openssl . The different SECLEVEL values are explained in this section of a specific manpage.
In the traceback messages above is are two specific examples.
In the first case (EE certificate key too weak) you can also check on the CLI like this:
echo Q | openssl s_client \
-CAfile "$(ucr get connector/ad/ldap/certificate)" \
-showcerts \
-starttls ldap \
-connect "$(ucr get connector/ad/ldap/host)":"$(ucr get connector/ad/ldap/port)" \
| less
And look for the line starting with Verification: . That s_client check uses starttls against the default AD LDAP port. If that doesn’t work you could also attempt direct SSL against the the LDAPS port 636, like
echo Q | openssl s_client \
-CAfile "$(ucr get connector/ad/ldap/certificate)" \
-showcerts \
-connect "$(ucr get connector/ad/ldap/host)":636 \
| less
But usually the starttls approach should work, because that’s what the AD-Connector uses (if the UCR variables are set to defaults (like connector/ad/ldap/ssl=yes etc.)).
Several things can make the verification fail. If this says EE certificate key too weak, then you can check the server certificate (part of the output) e.g. with openssl x509 -in <pasted servercertificate>.pem -noout -text | less. and look at the length of the key. If it e.g. days RSA Public-Key: (1024 bit), then the key is to short for the SECLEVEL=2. The proper thing in that case would be to let the MS AD server admin generate a new certificate for the AD DC. The not recommended temporary (!!!) workaround would be to edit /etc/ssl/openssl.cnf and lower the mandatory security to SECLEVEL=1.
In the second traceback example above the message was SSL routines:ssl_choose_client_version:unsupported protocol. That indicates that the server doesn’t support the default minimal protocol version of TLS 1.2. In that case the s_client test will not even show you the Certificate chain output.
If you are curious you could use the following command to check the protocols and ciphers that the remote host supports:
nmap --script ssl-enum-ciphers -p"$(ucr get connector/ad/ldap/port)" "$(ucr get connector/ad/ldap/host)"