[sr-dev] [kamailio/kamailio] load_crl takes 90 seconds to complete it execution with crl file size of 4MB !!! (#2312)

[maheshb2487]

<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.

If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:

  * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:

  * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.

If you submit a feature request (or enhancement) add the description of what you would like to be added.

If there is no content to be filled in a section, the entire section can be removed.

You can delete the comments from the template sections when filling.

You can delete next line and everything above before submitting (it is a comment).
-->

### Description

Am using Kamailio 5.1.9 version, In my tls.cfg i have one client and server profile,
along with default client and server profile.

I have crl enabled for the non default client and server profile , the crl file size is 4 MB in my case.

I have 22 child tcp process.

With this what i observe is load_crl is taking close to 90 seconds to finish its execution and return.


### Expected behavior

load_Crl function should not take 90 seconds to complete its execution.
probably it should take in the range of 10-15 seconds to complete its execution or even lesser.

#### Actual observed behavior

load_Crl function is taking 90 seconds to complete its execution.

#### Debugging Data

It is very clear from the code, its because of this for loop.
time taken to complete load_Crl execution is 90 seconds

 procs_no=get_max_procs();
for(i = 0; i < procs_no; i++) {
if (SSL_CTX_load_verify_locations(d->ctx[i], d->crl_file.s, 0) != 1) {
ERR("%s: Unable to load certificate revocation list '%s'\n",
tls_domain_str(d), d->crl_file.s);
TLS_ERR("load_crl:");
return -1;
}
store = SSL_CTX_get_cert_store(d->ctx[i]);
X509_STORE_set_flags(store,
X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
}


Is there a way this can be enhanced or as per the current kamailio design this is a must to do for each and every profile and its ssl context array list for each process and for every profile.

The same logic is seen in other load functions as well,  for example load_cert, 
load_ca_list,
load_crl,
set_cipher_list,
set_verification,
set_ssl_options,
set_session_cache,
ksr_tls_fix_domain,


#### Log Messages

<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->

```
(paste your log messages here)
```

#### SIP Traffic

<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->

```
(paste your sip traffic here)
```

### Possible Solutions

Reply from Henning Westerholt on posting this problem to Users Mailing list

"But the code could be probably also improved, maybe it is possible to parallelize it. You can open a feature request about it,"

### Additional Information

  Kamailio 5.1.9 version



* **Operating System**:

<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->

```
Linux Kernel version :  3.10.0-693.el7.x86_64


Centos version : CentOS Linux release 7.4.1708 (Core)


CPU : 2 cores with model name      : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz


[root at miv5000 ~]# cat /proc/meminfo
MemTotal:        3882076 kB
MemFree:          811244 kB
MemAvailable:    2320356 kB

 

Openssl verison : OpenSSL 1.0.2k-fips  26 Jan 2017
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2312
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200503/01474fc9/attachment-0001.html>