Being Kamailio specific coding, I added the config option and set it value as parameter to SSL_CTX_load_verify_locations() based on the feature request description, but it might not be complete implementation because its manual specify that the folder content is not send to client via SSL_CTX_set_client_CA_list(): * https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_load_verify_locations.ht… I haven't tested at all, not having a system that I could easily simulate the scenario. If not complete, feel free to add the missing part related, otherwise, if not useful at all, it can be reverted. -- 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/2682#issuecomment-804710128

Looks like installation of new version of kamailio had failed and tls module was not updated. Trying again ... -- 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/2682#issuecomment-804775191

The error message seems to be related to failure to open `ca_list` file, not to `ca_path` -- can you check if `ca_list` is still set somewhere there to an invalid file path? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2682#issuecomment-804799367

I pushed a commit to make that error message print the file name. Try again with latest master and paste here again the new error message to see what's there. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2682#issuecomment-804828670

Daniel-Constantin Mierla writes: Neither is contents of CAfile sent to client: In server mode, when requesting a client certificate, the server must send the list of CAs of which it will accept client certificates. This list is not influenced by the contents of CAfile or CApath and must explicitly be set using the SSL_CTX_set_client_CA_list(3) family of functions. -- Juha -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2682#issuecomment-804840617

Daniel-Constantin Mierla writes: Yes, it does work as client. I have two kamailios A - B using TLS between them. When A uses ca_path and B uses ca_list, A can connect to B without errors. But when I change also B to use ca_path, I get errors on both. On A: Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1283]: tls_h_read_f(): protocol level error Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS read:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1287]: tls_h_read_f(): source IP: 192.26.134.10 Mar 23 15:32:58 lohi /usr/bin/sip-proxy[18482]: ERROR: tls [tls_server.c:1290]: tls_h_read_f(): destination IP: 192.168.43.160 On B: Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls [tls_server.c:1283]: tls_h_read_f(): protocol level error Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls [tls_server.c:1287]: tls_h_read_f(): source IP: 192.168.43.160 Mar 23 15:32:58 buster /usr/bin/sip-proxy[2266]: ERROR: tls [tls_server.c:1290]: tls_h_read_f(): destination IP: 192.26.134.10 -- Juha -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2682#issuecomment-804910135

Both as client and as server work after command `c_rehash .` is executed in ca_path directory. It creates two (why two?) links to each ca certificate file, for example: ``` $ ls -ls total 16 0 lrwxrwxrwx 1 jh jh 18 Mar 24 07:58 12d55845.0 -> dst_root_ca_x3.pem 0 lrwxrwxrwx 1 jh jh 18 Mar 24 07:58 2e5ac55d.0 -> dst_root_ca_x3.pem 0 lrwxrwxrwx 1 jh jh 32 Mar 24 07:58 4a0a35c0.0 -> lets-encrypt-x3-cross-signed.pem 0 lrwxrwxrwx 1 jh jh 32 Mar 24 07:58 4f06f81d.0 -> lets-encrypt-x3-cross-signed.pem 0 lrwxrwxrwx 1 jh jh 14 Mar 24 07:58 590d426f.0 -> class3_X0E.crt 0 lrwxrwxrwx 1 jh jh 12 Mar 24 07:58 5ed36f99.0 -> root_X0F.crt 0 lrwxrwxrwx 1 jh jh 12 Mar 24 07:58 99d0fa06.0 -> root_X0F.crt 4 -rw-r--r-- 1 jh jh 2427 Mar 23 16:40 class3_X0E.crt 4 -rw-r--r-- 1 jh jh 1200 Mar 23 16:40 dst_root_ca_x3.pem 0 lrwxrwxrwx 1 jh jh 14 Mar 24 07:58 e5662767.0 -> class3_X0E.crt 4 -rw-r--r-- 1 jh jh 1647 Mar 23 16:40 lets-encrypt-x3-cross-signed.pem 4 -rw-r--r-- 1 jh jh 2464 Mar 23 16:40 root_X0F.crt ``` Text on page [https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_load_verify_locations.ht… is not very clear about the links: ` If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links. ` -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2682#issuecomment-805528425