libnetconf2
libnetconf2 copied to clipboard
Call-home Authentication Failure
Hi,
I am looking for a way to figure out that the call-home establishment failed because of authentication failure related to certificate in TLS mode. What I see is I get logs saying "certificate verify failed", but that error is not returned to main thread.
I looked at the code and saw that nc_accept_callhome returns only success(0) or failure(-1). It doesnt tell why the failure happened. Could you please let me know if it is possible to know the reason of call-home establishment failure?
I am using 1.x latest of all libnetconf2, sysrepo, netopeer2 code.
Hi,
Could anyone please comment on this.
Hi, to see if I can help on this, I have tried callhome. My Netopeer2-CLI listens and opens the port 4334 for SSH but not for TLS port 4335 with the command "listen --tls". I also have tried with crt. key. ca path options, but still the same. When I type "listen --tls" it returns command prompt right away ">" . I aready configured the server with tls_callhome.xml and it's trying the TLS connection to the port 4335.
Did you have to enable TLS listen on client side or it just worked?
I think you need to build libnetconf with TLS option, something like below: cmake -DENABLE_TLS=ON -DENABLE_SSH=ON -DCMAKE_BUILD_TYPE=Release
And normally I use full command because it needs certificates like below: listen --tls --cert /tmp/client.crt --key /tmp/client.key --trusted /tmp/ca.pem
hmm. I am already using TLS without callhome feature.. so I think building option is not the problem..
@michalvasko Could you please help here.
Any update here?
Sorry, I was on vacation. Did you follow these steps?
Hi @michalvasko ,
I am not facing problem related to establishing connection over TLS properly. But I want to handle one use case where certificates are not correct/invalid. So I want to know if it is possible to get the error returned to application when TLS call home fails because of certificate validation/authentication.
At that point you have no NETCONF session so the communication is strictly in TLS. And the error is only written, nothing else is possible to do with it.