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

Failed to set up mTLS sessions using certificate chain #417

Open
tieliao opened this issue Apr 19, 2023 · 2 comments
Open

Failed to set up mTLS sessions using certificate chain #417

tieliao opened this issue Apr 19, 2023 · 2 comments
Labels
is:bug Bug description. status:wontfix Issue is real, but for some reason, it won't be fixed.

Comments

@tieliao
Copy link
Contributor

tieliao commented Apr 19, 2023

Hi Michal,
My certificate file (server_chain.pem) of the callhome server contains 2 certificates:

  • the device certificate, which is issued by the intermediate CA
  • the intermediate CA certificate which is issued by the root CA

The root CA certificate is found in another file, server_root.pem.

My callhome server sends only the first certificate contained in server_chain.pem. So the verification failed at the peer, a physical device not based on libnetconf2.

Looking into session_server_tls.c, the following function is called:
SSL_CTX_use_certificate_file(tls_ctx, cert_path, SSL_FILETYPE_PEM)
I replaced it with
SSL_CTX_use_certificate_chain_file(tls_ctx, cert_path)

It works fine. I think that this fix could be compatible with the file which contains only one certificate, but I did not test it.

The same issue also exists in session_client_tls.c, where I also changed to
SSL_CTX_use_certificate_chain_file(opts->tls_ctx, opts->cert_path)

@michalvasko
Copy link
Member

Okay, I would say you are technically correct because of this description (although I am not sure what "configured" means here). I must have overlooked it and considered this subtree to set only the server certificate, with these certificate lists to supply all the CA certificates (even though, again, the description mentions its purpose and it does not include this one).

So, I am not strictly against changing it as it is obviously incorrect now. However, we are in the process of a major update of libnetconf2 that will use a different API (SO version 3). And I would prefer to wait with any significant changes (I consider this one to be such a change) for the release of that update and keep the functionality as it is now. Would that be acceptable for you?

Regarding the client TLS API, we are not following any standardized YANG modules there but I suppose the same change would make sense so I would either change none or both.

@michalvasko michalvasko added the is:bug Bug description. label Apr 20, 2023
@tieliao
Copy link
Contributor Author

tieliao commented Apr 20, 2023

To be clear, I used this code in the callhome server,
nc_client_tls_ch_set_cert_key_paths("server_chain.pem", "server_priv_key.pem");
nc_client_tls_ch_set_trusted_ca_paths("server_root.pem", NULL);

Otherwise OK to wait

@michalvasko michalvasko added the status:wontfix Issue is real, but for some reason, it won't be fixed. label Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:bug Bug description. status:wontfix Issue is real, but for some reason, it won't be fixed.
Projects
None yet
Development

No branches or pull requests

2 participants