This bug is created as a clone of upstream ticket:
https://pagure.io/freeipa/issue/8125

FreeIPA should use the system's crypto policy for TLS versions and ciphers instead of defining its own ranges in Apache HTTPd configuration and HTTPClient configuration. Crypto policy give admins one central place to set allow ciphers, minimal key length, minimal TLS version, and similar settings. The change is also required to align FreeIPA with packaging recommendations for [Fedora Crypto Policy](https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/) and RHEL.

The default settings also enable TLS 1.3. So far FreeIPA had TLS 1.3 support disabled in Apache HTTPd and on the client side because there were issues with post-handshake client cert authentication. The issues have been solved in recent python-urllib3, python-requests, and Apache HTTPd updates:

*  https://bugzilla.redhat.com/show_bug.cgi?id=1775158 Apache HTTPd bug "POST request with TLS 1.3 PHA client auth fails: Re-negotiation handshake failed: Client certificate missing"
* https://bugzilla.redhat.com/show_bug.cgi?id=1761403  "python-requests / urllib3: Enable post-handshake authentication for TLS 1.3"

## Required changes

* Enable TLS 1.3 PHA for clients
* Require HTTPd version with PHA fixes
* Enable TLS 1.3 on the client side
* Remove ``SSLProtocol`` stanza from HTTPd config file on RHEL
* Change ``SSLProtocol`` stanza to enable all versions except SSL 3.0, TLS 1.0, and TLS 1.1 on Fedora.

The DEFAULT crypto policy on Fedora still enables TLS 1.0 and 1.1, but we don't want to enable the old protocols on the server side.