Created attachment 1242726 [details] Output of sslscan tool against broken and working installation Description of problem: Recent update of NSS library left in Fedora 25 updates-testing (nss-3.28.1-1.2.fc25.x86_64) breaks FreeIPA installations due to the fact that LDAP client are unable to connect to configured directory server instance via StartTLS/LDAPS: {{{ Please add records in this file to your DNS system: /tmp/ipa.system.records.I5D5bB.db Restarting the web server Unable to set admin password Command '/usr/bin/ldappasswd -h master1.ipa.test -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpZ1Grqr -T /var/lib/ipa/tmp6RW64m uid=admin,cn=users,cn=accounts,dc=ipa,dc=test' returned non-zero exit status 1 Configuring client side components Using existing certificate '/etc/ipa/ca.crt'. Skip master1.ipa.test: cannot verify if this is an IPA server Failed to verify that master1.ipa.test is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. As this is IPA server, changes will not be rolled back. ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information }}} in the client self-enrollment logs, we can see that the LDAP bind fails during cipher negotiation as client and server can not agree on a common cipher: {{{ 2017-01-20T09:37:27Z DEBUG Verifying that master1.ipa.test (realm IPA.TEST) is an IPA server 2017-01-20T09:37:27Z DEBUG Init LDAP connection to: master1.ipa.test 2017-01-20T09:37:27Z DEBUG Error checking LDAP: Connect error: TLS error -12286:Cannot communicate securely with peer: no common encryption algorithm(s). 2017-01-20T09:37:27Z WARNING Skip master1.ipa.test: cannot verify if this is an IPA server }}} Similarly, manually connecting to LDAP via StartTLS/LDAPS also fails: {{{ # ldapsearch -ZZ -H ldaps://localhost ldap_start_tls: Can't contact LDAP server (-1) additional info: TLS error -12286:Cannot communicate securely with peer: no common encryption algorithm(s). }}} This precludes any secure connections to directory server and thus blocks successful installation of FreeIPA master, client enrollment and replica setup. Version-Release number of selected component (if applicable): nss-3.28.1-1.2.fc25.x86_64 freeipa-server-4.4.3-1.fc25.x86_64 389-ds-base-1.3.5.15-1.fc25.x86_64 openldap-clients-2.4.44-2.fc25.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install the RPMs mentioned in previous sections 2. Run ipa-server-install Actual results: Installation succeeds. Expected results: Installation fails due to errors in establishing secure LDAP connections.
Created attachment 1242801 [details] ssltap.txt
Thanks Kai, From that ssltap, it is apparent that the client does enable TLS v1.3 protocol (the extensions 40 and 43 are present, extension 43 lists support for draft 18 - 0x7f12), but it does not enable any of the TLSv1.3 specific ciphers - 0x1301, 0x1302, 0x1303, 0x1304, 0x1305 [1] - so establishing the connection is impossible and server correctly responds with handshake_failure alert. Solution for freeipa/ldap would be to either not enable TLSv1.3, enable TLSv1.3 and TLSv1.3 ciphers or (preferred) do not change the NSS TLS configuration and use Crypto Policy for configuration of TLS settings[2]. 1 - https://tools.ietf.org/html/draft-ietf-tls-tls13-18#appendix-A.4 2 - https://fedoraproject.org/wiki/Packaging:CryptoPolicies
In our case the client is libldap with NSS as TLS provider. It seems like libldap enabled TLS 1.3 by default. The server is 389-DS with NSS as well. I have to check why it has TLS 1.3 enabled. I know for sure that FreeIPA configures 389-DS with a custom list of allowed ciphers during installation. We might want to drop this and just use the default cipher list of NSS. Hubert told me that the default list is secure.
According to its configuration, the 389-DS instance on the test machine has TLS 1.3 disabled. sslVersionMin: TLS1.0 sslVersionMax: TLS1.2 $ ldapsearch -ZZ -D 'cn=Directory Manager' -W -H ldap://localhost -b cn=encryption,cn=config Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=encryption,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # encryption, config dn: cn=encryption,cn=config allowWeakCipher: off cn: encryption nsSSL3Ciphers: default nsSSLClientAuth: allowed nsSSLSessionTimeout: 0 objectClass: top objectClass: nsEncryptionConfig sslVersionMin: TLS1.0 nsSSLSupportedCiphers: TLS_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nsSSLSupportedCiphers: TLS_CHACHA20_POLY1305_SHA256::CHACHA20POLY1305::AEAD::2 56 nsSSLSupportedCiphers: TLS_AES_256_GCM_SHA384::AES-GCM::AEAD::256 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD: :128 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::1 28 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20 POLY1305::AEAD::256 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20PO LY1305::AEAD::256 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD: :256 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::2 56 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256::AES::SHA256::1 28 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384::AES::SHA384::2 56 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384::AES::SHA384::256 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20POLY 1305::AEAD::256 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1:: 128 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1:: 128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256::AES::SHA256::256 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1:: 256 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1:: 256 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_256_GCM_SHA384::AES-GCM::AEAD::256 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nsSSLSupportedCiphers: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA::CAMELLIA::SHA1::128 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLSupportedCiphers: TLS_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 nsSSLSupportedCiphers: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA::CAMELLIA::SHA1::256 nsSSLSupportedCiphers: TLS_RSA_WITH_SEED_CBC_SHA::SEED::SHA1::128 nsSSLSupportedCiphers: TLS_RSA_WITH_3DES_EDE_CBC_SHA::3DES::SHA1::192 nsSSLSupportedCiphers: TLS_RSA_WITH_RC4_128_SHA::RC4::SHA1::128 nsSSLSupportedCiphers: TLS_RSA_WITH_RC4_128_MD5::RC4::MD5::128 nsSSLSupportedCiphers: TLS_DHE_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 nsSSLSupportedCiphers: TLS_DHE_DSS_WITH_DES_CBC_SHA::DES::SHA1::64 nsSSLSupportedCiphers: TLS_RSA_WITH_DES_CBC_SHA::DES::SHA1::64 nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 nsSSLSupportedCiphers: TLS_ECDHE_RSA_WITH_NULL_SHA::NULL::SHA1::0 nsSSLSupportedCiphers: TLS_ECDH_RSA_WITH_NULL_SHA::NULL::SHA1::0 nsSSLSupportedCiphers: TLS_ECDH_ECDSA_WITH_NULL_SHA::NULL::SHA1::0 nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_SHA::NULL::SHA1::0 nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_SHA256::NULL::SHA256::0 nsSSLSupportedCiphers: TLS_RSA_WITH_NULL_MD5::NULL::MD5::0 nssslenabledciphers: TLS_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nssslenabledciphers: TLS_CHACHA20_POLY1305_SHA256::CHACHA20POLY1305::AEAD::256 nssslenabledciphers: TLS_AES_256_GCM_SHA384::AES-GCM::AEAD::256 nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::1 28 nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20PO LY1305::AEAD::256 nssslenabledciphers: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20POLY 1305::AEAD::256 nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nssslenabledciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nssslenabledciphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nssslenabledciphers: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256::CHACHA20POLY13 05::AEAD::256 nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nssslenabledciphers: TLS_DHE_DSS_WITH_AES_128_CBC_SHA::AES::SHA1::128 nssslenabledciphers: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nssslenabledciphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nssslenabledciphers: TLS_DHE_DSS_WITH_AES_256_CBC_SHA::AES::SHA1::256 nssslenabledciphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 nssslenabledciphers: TLS_RSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 nssslenabledciphers: TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 nssslenabledciphers: TLS_RSA_WITH_AES_128_CBC_SHA256::AES::SHA256::128 nssslenabledciphers: TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nssslenabledciphers: TLS_RSA_WITH_AES_256_CBC_SHA256::AES::SHA256::256 nsSSL2: off nsSSL3: off nsTLS1: on sslVersionMax: TLS1.2 # RSA, encryption, config dn: cn=RSA,cn=encryption,cn=config cn: RSA nsSSLActivation: on nsSSLPersonalitySSL: Server-Cert nsSSLToken: internal (software) objectClass: top objectClass: nsEncryptionModule # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2
The startup log for 389-DS says that it has TLS 1.3 enabled. It contradicts the values in cn=encryption,cn=config. [20/Jan/2017:12:21:43.392275455 +0100] SSL alert: Security Initialization: Enabling default cipher set. [20/Jan/2017:12:21:43.394692646 +0100] SSL alert: Configured NSS Ciphers [20/Jan/2017:12:21:43.396532427 +0100] SSL alert: TLS_AES_128_GCM_SHA256: enabled [20/Jan/2017:12:21:43.398188842 +0100] SSL alert: TLS_CHACHA20_POLY1305_SHA256: enabled [20/Jan/2017:12:21:43.399739538 +0100] SSL alert: TLS_AES_256_GCM_SHA384: enabled [20/Jan/2017:12:21:43.401377726 +0100] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [20/Jan/2017:12:21:43.403380409 +0100] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Jan/2017:12:21:43.405172237 +0100] SSL alert: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled [20/Jan/2017:12:21:43.406907371 +0100] SSL alert: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [20/Jan/2017:12:21:43.408401533 +0100] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [20/Jan/2017:12:21:43.409959655 +0100] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [20/Jan/2017:12:21:43.411726408 +0100] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Jan/2017:12:21:43.413183516 +0100] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [20/Jan/2017:12:21:43.414869511 +0100] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Jan/2017:12:21:43.416444533 +0100] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Jan/2017:12:21:43.418008226 +0100] SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Jan/2017:12:21:43.419633218 +0100] SSL alert: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled [20/Jan/2017:12:21:43.421273013 +0100] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Jan/2017:12:21:43.422934354 +0100] SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [20/Jan/2017:12:21:43.424567189 +0100] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Jan/2017:12:21:43.426224006 +0100] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Jan/2017:12:21:43.427839095 +0100] SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [20/Jan/2017:12:21:43.429640172 +0100] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Jan/2017:12:21:43.431426045 +0100] SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Jan/2017:12:21:43.433083291 +0100] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [20/Jan/2017:12:21:43.434599471 +0100] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Jan/2017:12:21:43.436011163 +0100] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [20/Jan/2017:12:21:43.437544750 +0100] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Jan/2017:12:21:43.449406482 +0100] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.3 [20/Jan/2017:12:21:43.451608332 +0100] 389-Directory/1.3.5.15 B2016.308.2026 starting up
(In reply to Christian Heimes from comment #5) > The startup log for 389-DS says that it has TLS 1.3 enabled. It contradicts > the values in cn=encryption,cn=config. but it does look like NSS default (and TLSv1.3 specific ciphers look to be enabled), so it looks like the issue is on the client side
Updates for Fedora 24 and Fedora 25 have been pushed, which disable TLS 1.3. Do you think it's acceptable to keep TLS 1.3 enabled on Rawhide 26 ? It will allow you to test more easily if you've fixed it, and it would allow us to find other broken applications.
Could you please give us feedback, if FreeIPA works with the submitted F24 + F25 updates?
(In reply to Kai Engert (:kaie) from comment #7) > Updates for Fedora 24 and Fedora 25 have been pushed, which disable TLS 1.3. > > Do you think it's acceptable to keep TLS 1.3 enabled on Rawhide 26 ? > > It will allow you to test more easily if you've fixed it, and it would allow > us to find other broken applications. We shouldn't break rawhide intentionally either, so probably we should keep TLS 1.3 disabled. Matus Honek said he'll work on fixing openldap handling of ciphersuites this week, so we should be able to resume testing of TLS 1.3 next week.
(In reply to Hubert Kario from comment #9) > > Matus Honek said he'll work on fixing openldap handling of > ciphersuites this week, so we should be able to resume testing of TLS 1.3 > next week. Is there a Fedora bug that tracks this work? Has there been any progress on fixing openldap? We would like to try to enable TLS 1.3 in Fedora again, and this issue is a blocker for that effort.
The identified problem is with the openldap component, so let's reassign this bug.
Created attachment 1265834 [details] Add support for TLSv1.3 ciphers in OpenLDAP I'm attaching a proposed patch (it probably won't apply cleanly to the dist-git repo due to some of my local changes). Hubert, please, check if the flags in the cipher suite definitions are correct. I've tested with TLS_PROTOCOL_MIN 3.4 with both client and server and all three ciphers were sent in the Client Hello with TLS connection successfully established. I'll file separate bugzillas for f25 and f26 for this issue. Thanks.
Here is a COPR repository with NSS builds that enable TLS 1.3 support: https://copr.fedorainfracloud.org/coprs/kengert/nss-with-tls-1.3/
Comment on attachment 1265834 [details] Add support for TLSv1.3 ciphers in OpenLDAP r+ but the "TLSv1.3" alias is not exactly set in stone just yet: https://github.com/openssl/openssl/issues/2276
Thanks, Hubert. I am aware of the alias not being official (I came across the very same GitHub issue), yet, but I wanted to make choosing those ciphers through TLS_CIPHER_SUITE possible. Same as the TLSv1.3, it is a subject to a potential change.
This bug is resolved now by bug 1435689 and bug 1435692. Should the issues still persist, please, feel free to reopen this bug.