ODL控制器部署Netconf TestTool后连接触发InvalidKeyException问题求助

嘿，我之前也碰到过ODL跨版本对接Netconf测试工具的类似问题，这个InvalidKeyException十有八九是加密套件/密钥配置不兼容搞的鬼——毕竟你用的是Boron版本的测试工具，对接的却是Nitrogen版本的控制器，两个版本差了好几个迭代，安全策略上肯定有差异。给你整理了几个一步步排查的思路：

1. 先核对两边JVM的安全配置 #

Boron和Nitrogen依赖的JVM加密规则可能不一样，比如Nitrogen默认禁用了一些旧的弱加密算法，但Boron的测试工具还在尝试用它们。

• 分别查看控制器和测试工具所在JVM的java.security文件（路径一般是$JAVA_HOME/jre/lib/security/java.security），重点看jdk.tls.disabledAlgorithms和jdk.certpath.disabledAlgorithms这两项。
• 试试把测试工具JVM的这两个配置项改成和控制器完全一致，或者临时注释掉测试工具里禁用的部分算法，重启测试工具再看能不能正常连接。

2. 检查Netconf Connector的安全参数 #

你通过REST添加connector的时候，有没有指定过安全相关的参数？如果没指定，ODL会用Nitrogen的默认加密套件，而这套可能和Boron测试工具不兼容。

• 用Karaf命令netconf-connector:list或者RESTCONF接口查看connector的详细配置，重点看ssh-client-config下的algorithms字段（包括key-exchange、cipher、mac这些）。
• 如果发现配置里用了Boron不支持的新算法，就手动指定一套兼容的，比如在创建connector的REST请求里加上：

  "ssh-client-config": {
    "algorithms": {
      "key-exchange": ["diffie-hellman-group1-sha1", "diffie-hellman-group14-sha1"],
      "cipher": ["aes128-cbc", "3des-cbc"],
      "mac": ["hmac-sha1"]
    }
  }
  

  这些都是Boron版本肯定支持的老算法，先试试能不能绕过异常。

3. 开Debug日志抓细节 #

光看异常栈不够，得抓加密握手过程的具体日志才能定位到到底是哪个密钥/算法出问题了：

• 给ODL控制器开Netconf相关的Debug日志：在Karaf控制台执行log:set DEBUG org.opendaylight.netconf，然后触发连接，看日志里的TLS握手报错细节。
• 给测试工具加日志参数启动：java -Xmx1G -Dorg.slf4j.simpleLogger.defaultLogLevel=debug -jar netconf-testtool-1.1.0-Boron-executable.jar，这样能看到测试工具这边发起连接时的加密协商过程，找到抛出异常的具体环节。

4. 版本对齐才是长久之计 #

跨版本对接总有各种坑，长远来看，最好把测试工具升级到和控制器匹配的Nitrogen版本（对应netconf-testtool-1.4.0-Nitrogen-executable.jar），版本一致的话安全配置、协议细节都会兼容很多，也能避免其他潜在的奇怪问题。

5. 检查密钥对/证书的有效性 #

如果你们用了自定义的密钥或证书，得确认密钥长度是否符合要求——比如Nitrogen可能要求RSA密钥至少2048位，但Boron测试工具默认生成的可能是1024位，这也会触发InvalidKeyException。

• 用ssh-keygen -l -f <密钥文件路径>检查测试工具的密钥长度，要是不够的话重新生成符合要求的密钥对替换掉默认的。

内容的提问来源于stack exchange，提问作者Simon Jack