mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
cert-find is a rather complex beast because it not only looks for certificates in the optional CA but within the IPA LDAP database as well. It has a process to deduplicate the certificates since any PKI issued certificates will also be associated with an IPA record. In order to obtain the data to deduplicate the certificates the cert from LDAP must be parser for issuer and serial number. ipaldap has automation to determine the datatype of an attribute and will use the ipalib.x509 IPACertificate class to decode a certificate automatically if you access entry['usercertificate']. The downside is that this is comparatively slow. Here is the parse time in microseconds: cryptography 0.0081 OpenSSL.crypto 0.2271 ipalib.x509 2.6814 Since only issuer and subject are required there is no need to make the expensive IPACertificate call. The IPACertificate parsing time is fine if you're parsing one certificate but if the LDAP search returns a lot of certificates, say in the thousands, then those microseconds add up quickly. In testing it took ~17 seconds to parse 5k certificates (excluding transmission overhead, etc). cert-find when there are a lot of certificates has been historically slow. It isn't related to the CA which returns large sets (well, 5k anyway) in a second or two. It was the LDAP comparision adding tens of seconds to the runtime. When searching with the default sizelimit of 100 the time is ~10s without this patch. With it the time is 1.5s. CLI times from before and after searching for all certs: original: ------------------------------- Number of entries returned 5038 ------------------------------- real 0m15.507s user 0m0.828s sys 0m0.241s using cryptography: real 0m4.037s user 0m0.816s sys 0m0.193s Fixes: https://pagure.io/freeipa/issue/9331 Signed-off-by: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>