Closed alanik99 closed 11 months ago
Could you please be more specific and include an exact description of a particular use-case when you change a single parameter and the server continues to use the old one? Or that is what I understood the problem you are having.
I changed not only one certificate but them all to connect with new certificates signed with new CA.
Requests I've sent (I changed keys/certs used in requests to ...test-...
for security reasons):
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ncs="urn:ietf:params:xml:ns:yang:ietf-netconf-server"
message-id="1">
<edit-config>
<target>
<running/>
</target>
<config>
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<listen>
<endpoint>
<name>default-tls</name>
<tls>
<tls-server-parameters>
<client-authentication>
<cert-maps>
<cert-to-name>
<id>1</id>
<fingerprint>02:...test-CA-fingerprint...</fingerprint>
</cert-to-name>
</cert-maps>
</client-authentication>
</tls-server-parameters>
</tls>
</endpoint>
</listen>
</netconf-server>
</config>
</edit-config>
</rpc>
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ks="urn:ietf:params:xml:ns:yang:ietf-keystore"
message-id="1">
<edit-config>
<target>
<running/>
</target>
<config>
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
<asymmetric-keys>
<asymmetric-key>
<name>serverkey</name>
<algorithm>rsa2048</algorithm>
<public-key>...test-serverpubkey...</public-key>
<private-key>...test-serverprivkey...</private-key>
<certificates>
<certificate>
<name>servercert</name>
<cert>...test-servercert...</cert>
</certificate>
</certificates>
</asymmetric-key>
</asymmetric-keys>
</keystore>
</config>
</edit-config>
</rpc>
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ts="urn:ietf:params:xml:ns:yang:ietf-truststore"
message-id="1">
<edit-config>
<target>
<running/>
</target>
<config>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
<certificates>
<name>clientcerts</name>
<certificate>
<name>clientcert</name>
<cert>...test-clientcert...</cert>
</certificate>
</certificates>
<certificates>
<name>cacerts</name>
<certificate>
<name>cacert</name>
<cert>...test-cacert...</cert>
</certificate>
</certificates>
</truststore>
</config>
</edit-config>
</rpc>
And netopeer continues using an old CA fingerprint after these changes were applied. (Only after restarting netopeer it starts to use the new CA fingerprint)
Right, modifications of CTN entries were being ignored, should be correctly applied now in latest devel
of netopeer2.
Could you please give a commit id or MR on these changes?
It's referenced in this issue, right above my previous post...
Ah, I see. Thank you Tested - now it works.
Hello!
It was noticed that if I change TLS client, server, CA certificates/keys to new ones, it connects with the new ones then only after restarting netopeer2-server. But it works without restarting if delete changed
<cert-to-name>
element and add the same<cert-to-name>
element again.When it doesn't connect, in logs I see "Cert-to-name unsuccessful, dropping the new client" message. While I debugged netopeer with gdb before restarting it, I had noticed that during handshake the old CA fingerprint was used indeed. In netopeer sources I see there's a change callback on cert-maps:
Then I manually changed
<fingerprint>
inside<cert-to-name>
element withsysrepocfg --edit=vi -m ietf-netconf-server
(changed one arbitrary chosen character in the fingerprint), then inside the callback I see thatsr_get_change_tree_next(session, iter, &op, &node, NULL, NULL, NULL))
call inwhile
condition returns SR_ERR_NOT_FOUND and writes NULL to &node.Packages versions I use:
-- Regards, Alexander