As an admin, I want OCSP stapling on TLS responses from FreeIPA servers so that on-line OCSP checks aren't needed.
If the OCSP response was stapled to the TLS handshake, an additional round-trip wouldn't be required, improving performance and reliability.
See also https://pagure.io/freeipa/issue/7846.
openssl s_client -connect ipa.example.com:443 -status </dev/null | grep OCSP openssl s_client -connect ipa.example.com:389 -starttls ldap -status </dev/null | grep OCSP
ipa-server-4.6.4-10.el7.centos.x86_64 ipa-client-4.6.4-10.el7.centos.x86_64 389-ds-base-1.3.8.4-18.el7_6.x86_64 pki-ca-10.5.9-6.el7.noarch krb5-server-1.15.1-34.el7.x86_64
On the HTTPS side, this can be achieved with just a few extra lines of Apache config (see, e.g., https://mozilla.github.io/server-side-tls/ssl-config-generator/). I suspect it will be more difficult for LDAPS.
Please note that the OCSP request discussed in SSSD ticket https://pagure.io/SSSD/sssd/issue/3922 was issued to validate a user certificate to see if the key can be used for ssh authentication. So I think using OCSP stapling on TLS responses does not help here.
it's pretty easy to enable OCSP stapling Apache HTTPd. It's basically two config lines on Fedora and RHEL:
SSLUseStapling On
SSLStaplingCache shmcb:/var/cache/httpd/ssl/ocsp_cache(10485760)
389-DS uses NSS. I haven't found any code related to OCSP in 389-ds-base. Please open a ticket at https://pagure.io/389-ds-base/ to request OCSP stapling support from 389-DS.
Please note that most clients do not have any code to request and verify OCSP stapling information. I know for sure that neither Python nor OpenLDAP client supports OCSP yet.
The reporter is using 4.6.4 in RHEL 7 which still uses mod_nss for TLS support. Last I checked NSS doesn't support OCSP stapling on the server-side.
Ah-ha! I had overlooked this feature, because although it's present in EL 6 it isn't documented until EL 7, and so miss-assumed the cause of the OCSP requests. Thanks. I have updated the issue description.
Login to comment on this ticket.