Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add ca_path param to tls module #2682

Closed
juha-h opened this issue Mar 17, 2021 · 15 comments
Closed

add ca_path param to tls module #2682

juha-h opened this issue Mar 17, 2021 · 15 comments

Comments

@juha-h
Copy link
Contributor

juha-h commented Mar 17, 2021

Currently tls module has ca_list param that

Sets the CA list file name. This file contains a list of all the trusted CAs certificates used when connecting to other SIP implementations. If a signature in a certificate chain belongs to one of the listed CAs, the verification of that certificate will succeed.

This issue proposes adding a new tls param ca_path. Its value would be a directory that contains any number of CA certificate files thus making it unnecessary to cat these files to a single ca_list file.

Implementation could be based on the same int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile, const char *CApath) OpenSSL API function as now.

@oej
Copy link
Member

oej commented Mar 18, 2021

Good idea.

miconda added a commit that referenced this issue Mar 23, 2021
- used to provide path to directory with CA files in pem format, to be
given as parameter to SSL_CTX_load_verify_locations()
- GH #2682
@miconda
Copy link
Member

miconda commented Mar 23, 2021

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 specifies that the folder content is not send to client via SSL_CTX_set_client_CA_list():

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.

@juha-h
Copy link
Contributor Author

juha-h commented Mar 23, 2021 via email

@juha-h
Copy link
Contributor Author

juha-h commented Mar 23, 2021 via email

@kamailio-sync
Copy link

kamailio-sync commented Mar 23, 2021 via email

@miconda
Copy link
Member

miconda commented Mar 23, 2021

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?

@juha-h
Copy link
Contributor Author

juha-h commented Mar 23, 2021 via email

@miconda
Copy link
Member

miconda commented Mar 23, 2021

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.

@kamailio-sync
Copy link

kamailio-sync commented Mar 23, 2021 via email

@juha-h
Copy link
Contributor Author

juha-h commented Mar 23, 2021 via email

@miconda
Copy link
Member

miconda commented Mar 23, 2021

Pushed a commit to fix the error message.

The SSL_CTX_set_client_CA_list() is used with the ca_list file, the error message above is actually when that is done.

@kamailio-sync
Copy link

kamailio-sync commented Mar 23, 2021 via email

@miconda
Copy link
Member

miconda commented Mar 23, 2021

As I said, I added the parameter based on the description of the feature request, but the manual suggested it might not be enough when acting as a tls server, see my first comment above.

Probably works when it acts as a client (when opens the connection).

You can dig further in the libssl docs to see what has to be done for server case and you can update the load_ca_list() function from tls_domain.c.

@juha-h
Copy link
Contributor Author

juha-h commented Mar 23, 2021 via email

@juha-h
Copy link
Contributor Author

juha-h commented Mar 24, 2021

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.html 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.

@juha-h juha-h closed this as completed Mar 24, 2021
piotr-gregor pushed a commit to signalwire/kamailio-shaken that referenced this issue Mar 26, 2021
- used to provide path to directory with CA files in pem format, to be
given as parameter to SSL_CTX_load_verify_locations()
- GH kamailio#2682
NGSegovia pushed a commit to NGSegovia/kamailio that referenced this issue Aug 26, 2021
- used to provide path to directory with CA files in pem format, to be
given as parameter to SSL_CTX_load_verify_locations()
- GH kamailio#2682
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants