當我在節點中向 Axios 發出請求時遇到問題：錯誤：ca md 太弱。
我正在發送 pfx 證書檔案的 .pfx 檔案和密碼。我可以使用 Postman 輕松訪問 API 并發送 pfx 證書和密碼，但是在節點 js (v. 18.0) 中使用 Axios 發出請求時出現錯誤：ca md 太弱。
我不想降級節點版本并使用： 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)
uj5u.com熱心網友回復：
TLDR：如果您不關心理解，請跳到結尾
rejectUnauthorized指示 nodejs 接受服務器使用的（某些）無效證書而不是中止連接，但此錯誤發生在您自己的客戶端證書/鏈上，而不是服務器的證書/鏈上。（這就是為什么即使沒有實際連接所需的 VPN 也會發生這種情況。）“CA_MD_TOO_WEAK”檢查發生在 OpenSSL 的現代版本（1.1.0 以上）中，但可能會根據 OpenSSL 的構建方式而有所不同，因此對于 nodejs還取決于您的 nodejs 是使用其自己的嵌入式 OpenSSL（通常在 Windows 上）還是已經在安裝它的系統上提供的（通常在 Linux 上）。
如果您在這臺機器上擁有（或獲得）它，或者您（可能、可以并且確實）將 pfx 復制到同上的機器，則可以使用 openssl 查看證書鏈中使用的簽名演算法。先做
openssl pkcs12 -in yourpfxfile -nokeys >temp0
看看temp0；它應該包含一個或多個塊，每個塊由subject=一行、issuer=一行、-----BEGIN CERTIFICATE-----一行、幾行base64和-----END CERTIFICATE-----一行組成。（可能還有一些Bag Attributes:行可選地后跟縮進行；忽略那些。）
如果只有一個塊并且它與 and 具有相同的值subject，issuer那么您的錯誤不應該發生，因為證書是自簽名的，OpenSSL 不應該檢查自簽名證書的簽名強度。否則，做
openssl x509 -in temp0 -noout -text -certopt no_pubkey,no_sigdump,no_extensions
你應該得到幾行輸出，其中包括signatureAlgorithm: xwhere xis 的形式{hash}withRSAEncryption ecdsa_with_{hash} dsa-with-{hash} or dsaWith{hash}。如果{hash}是 MD5，則證書上的簽名很弱，并且不提供它聲稱的安全性 - 盡管在您的情況下，如果服務器接受它，盡管存在這種弱點，這可能不是您的問題。
如果第一個（葉子）證書不是自簽名的（subject不一樣issuer）并且其簽名演算法不使用 MD5，要么
您的 nodejs 使用的 OpenSSL 設定為高于通常的“安全級別”——這對于嵌入了 OpenSSL 的 nodejs 不太可能，但對于系統提供的 nodejs 來說更合理，尤其是在像 RedHat 8 這樣以安全為重點的系統上；或者
問題出在第一個證書以外的證書（即 CA 證書）上，但如果您的證書來自正常運行的 CA，則不會發生這種情況，因為這樣的 CA 永遠不應有更高的 CA 證書簽名比葉子證書更弱的密鑰或簽名演算法，除了簽名無關緊要的自簽名根，并且不檢查因此不會導致您的錯誤。但是，如果您愿意，可以將除第一個以外的每個塊分成一個單獨的檔案，并對每個塊重復上述
openssl x509程序，除非最后一個塊具有subject并且issuer同樣不要檢查它，因為它是自簽名的根證書。
無論如何，解決方法：添加到您的 https-Agent options ciphers: "DEFAULT:@SECLEVEL=0"。這應該會關閉幾項旨在防止不安全 SSL/TLS 連接的檢查，包括此處相關的一項；因此，如果您使用此代碼處理任何重要的資料，則可能會面臨更高的風險，具體取決于服務器的作業。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/494052.html
上一篇：如何知道何時創建副本？