Hi Sami,

OpenLDAP does not seem to be properly configurable for TLSv1.3 currently (although it works just ok with it with OpenSSL-default ciphers pre-set). OpenSSL, which OpenLDAP uses, has new options for TLSv1.3 that need to be implemented in OpenLDAP first (ciphersuites are set differently, see the `man ciphers`).

In your case, you did not mention explicitly if it is so, you should make sure the server has TLSv1.3 disabled by setting the `sslVersionMax: TLS1.2`. Then, it should be impossible to negotiate TLSv1.3 even though the client supports it. Please, let me know if this helped.

Also, please note, as it is also mentioned in the `man ciphers`, that:
1. There is no TLSv1.3 keyword for OpenSSL ciphers.
2. Setting any of the TLSv* or SSL* keywords for the ciphers does not disable the protocol itself.

Hope this helps,
Matus

Thanks Matus,

Situation is so that I have 389ds (Directory server) acting as a LDAP server. It's running on a top of RedHat7 and there shouldn't be any configuration (nor support) for TLSv1.3 at all. 
I was hoping that there would be some sslversionmax in ldap.conf which would be used by ldap clients. But after reading your mail, I have started to wonder actions of our ldap server.

No when you mentioned that impossilibity. I didn't event think about the server side because I have made scans, it only shows that It can negotiate TLSv1.2. Because it's also oldish, I didn't even think that it could be the problem with TLSv1.3 case. But now this makes me wonder why it then tries to establish TLSv1.3 link? It sure has sslversionmax attribute which I think makes the trick. I have to give it a try.

Thanks Matus!

The support very much depends on the crypto library and in case of NSS (which is used in 389ds) it actually does "since Firefox (tm)" which needs it; but in general security tends to be more up-to-date since... well, security is important. I know there were some issues some months ago where 389ds would pick up TLSv1.3 although it shouldn't but that should be fixed now, just make sure you are on the latest, it was fixed somewhere after 389-ds-base-1.3.10. But explicit override (as discussed) should work anyway.

I should be on latest.

* openssl-1.0.2k-19.el7.x86_64
* 389-ds-base-1.3.10.1-5.el7.x86_64

Our 389ds had sslversionmax set to 1.3, which was weird. I don't think it would have been set originally, maybe some update had updated that when support arrived. But now everything works with 1.2, that's not a fix thou if it should work with 1.3 also.

// Sami

I'm seeing this same error for sssd when trying to add a new CentOS 8.3 container to and existing CentOS 7 environment with 389-ds as the directory server.

(2021-02-16 10:49:45): [be[LDAP]] [sdap_connect_done] (0x0080): START TLS result: Success(0), Start TLS request accepted.Server willing to negotiate SSL.
(2021-02-16 10:49:45): [be[LDAP]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure]

Also getting it for ldapsearch running on CentOS 8.3:

env LDAPTLS_CACERT=/etc/openldap/certs/cert.pem ldapsearch -ZZ -H ldap://389-ds-1:389/ -D uid=aki,ou=people,dc=environment,dc=company,dc=com -W -b ou=people,dc=environment,dc=company,dc=com uid=aki

ldap_start_tls: Connect error (-11)
        additional info: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

I was able to switch to nss-pam-ldapd and nscd instead of sssd with the following config in /etc/nslcd.conf:

uid nslcd
gid ldap
uri ldap://389-ds-1/
uri ldap://389-ds-2/
ldap_version 3
base dc=environment,dc=company,dc=com
binddn uid=dirquery,ou=People,dc=environment,dc=company,dc=com
bindpw password
scope sub
base   group  ou=Groups,dc=environment,dc=company,dc=com
base   passwd ou=People,dc=environment,dc=company,dc=com
base   shadow ou=People,dc=environment,dc=company,dc=com
tls_cacertfile /etc/openldap/certs/cert.pem
tls_ciphers HIGH:+TLSv1.2:-TLSv1.3

If I add that last config entry to sssd.conf as

ldap_tls_cipher_suite = HIGH:+TLSv1.2:-TLSv1.3

the problem doesn't get resolved.

Sorry, I read the thread without noticing that setting "sslVersionMax: TLS1.2" would fix it. It worked with 389-ds for me too.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.