节点TLS错误:向Axios发出请求时ca md太弱

Question

当我在节点获取错误时向Axios发出请求时，遇到了一个问题: ca md太弱了。

我正在为pfx证书文件发送.pfx文件和密码。我可以很容易地使用Postman访问API，并发送pfx证书和密码，但是在节点js中使用Axios发出请求(v.18.0)我得到了错误: ca md太弱了。

我不想降级Node版本，并使用: process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0；也没有帮助。

另外，要连接到服务器，我必须使用VPN，即使没有打开VPN，也会弹出此错误。

可以绕过这张支票吗?这样我就可以像邮递员一样发送请求了吗？

下面是一个代码示例：

agent = new https.Agent({
    pfx: fs.readFileSync((process.cwd() + "\\src\\sources\\KIISWSClient.pfx")),
    passphrase: 'password',
    rejectUnauthorized: false,
  });

  userKiisData = axios.post('https://ws-kiis.hlk.hr/AdeoMembersPublicService.svc/WSPublic/BasicData', {
    Username: "myusername",
    Role: "role"
  }, {
    auth: {
      username: "user",
      password: "mypassword"
    },
    httpsAgent: agent
  }
return userKiisData

以下是错误：

Error: ca md too weak
    at configSecureContext (node:internal/tls/secure-context:278:15)
    at Object.createSecureContext (node:_tls_common:113:3)
    at Object.connect (node:_tls_wrap:1622:48)
    at Agent.createConnection (node:https:142:22)
    at Agent.createSocket (node:_http_agent:343:26)
    at Agent.addRequest (node:_http_agent:294:10)
    at new ClientRequest (node:_http_client:311:16)
    at Object.request (node:https:352:10)

Answer 1

TLDR:如果你不关心理解，就跳到最后

rejectUnauthorized指示nodejs接受服务器使用的(某些)无效证书，而不是中止连接，但此错误发生在您自己的客户端证书/链上，而不是服务器的客户端证书/链上。(这就是即使没有实际连接所需的VPN也可能发生的原因。)"CA_MD_TOO_WEAK“检查发生在OpenSSL的现代版本(1.1.0up)中，但取决于OpenSSL的构建方式，因此对于nodejs来说，它还取决于您的nodejs是用于使用自己的嵌入式OpenSSL (在Windows上通常是这样)还是已经在安装它的系统上提供的(通常在Linux上)。

如果您在这台机器上拥有(或获得)证书链中使用的签名算法，或者您(可以、可以和确实)将pfx复制到一台机器上，您可以查看它。先做

openssl pkcs12 -in yourpfxfile -nokeys >temp0

查看temp0；它应该包含一个或多个块，每个块由一条subject=行、一条issuer=线、一条-----BEGIN CERTIFICATE-----行、几行base64和一条-----END CERTIFICATE-----行组成。(很可能也有Bag Attributes:行可选地后面跟着缩进行；忽略这些行。)

如果只有一个块，并且它对subject和issuer具有相同的值，那么您的错误就不应该发生，因为证书是自签名的，OpenSSL不应该检查自签名证书上的签名强度。否则，做

openssl x509 -in temp0 -noout -text -certopt no_pubkey,no_sigdump,no_extensions

您应该得到几行输出，其中包括signatureAlgorithm: x，其中x的形式是{hash}withRSAEncryption ecdsa_with_{hash} dsa-with-{hash} or dsaWith{hash}。如果{hash}是MD5，则证书上的签名是弱的，不能提供它声称的安全性--尽管在您的情况下，尽管存在此缺陷，但服务器还是接受它，这可能不是您的问题。

如果第一个(叶)证书不是自签名的(subject与issuer不相同)，而且其签名算法也不使用MD5

nodejs使用的

1. 被设置为比通常的“安全级别”更高的“安全级别”--对于嵌入了OpenSSL的nodejs来说，这不太可能，但对于一个系统(特别是针对以安全为重点的系统，如RedHat 8；或

)来说，则不太可能。

1. 问题在于第一个证书(即CA证书)以外的证书，但是如果您的证书来自正确运行的CA，则不应该发生这种情况，因为这样的CA不应该有比叶证书更弱的密钥或签名算法签名的更高的CA证书，除非签名不重要的自签名根，而且不检查它不会导致您的错误。但是，如果需要，将第一个块以外的每个块分割成一个单独的文件，并在每个文件上重复上面的openssl x509过程，除非最后一个块具有subject和issuer --同样不要检查它，因为它是自签名根证书.

。

无论如何，解决方案：添加到您的https-代理选项ciphers: "DEFAULT:@SECLEVEL=0"。这将关闭几个旨在防止不安全的SSL/TLS连接的检查，包括此处相关的检查；因此，如果您使用此代码处理任何重要的数据，则可能会因服务器的操作而面临更高的风险。