3 回答

TA貢獻(xiàn)1868條經(jīng)驗(yàn) 獲得超4個(gè)贊
我不確定如何處理錯(cuò)誤消息
無法驗(yàn)證 127.0.0.1 的證書,因?yàn)樗话魏?IP SAN
因?yàn)槲以趧?chuàng)建證書時(shí)傳入了 IPAddresses 字段。關(guān)于這里有什么問題的任何想法?
問題是您在創(chuàng)建客戶端IPAddresses證書時(shí)傳遞了該字段,而不是在創(chuàng)建服務(wù)器證書時(shí)傳遞,因?yàn)槟姆?wù)器只是將 CA 證書用作自己的證書,而 CA 證書(正確) 不包括 IP 地址,因此錯(cuò)誤消息是正確的:
caKey, caKeyPEM := generateKey(t)
caCert, caCertPEM := generateRootCert(t, caKey)
serverCert, err := tls.X509KeyPair(caCertPEM, caKeyPEM)
您應(yīng)該以與創(chuàng)建客戶端證書相同的方式創(chuàng)建由 CA(或 CA)簽名的服務(wù)器證書,并將其用于測試服務(wù)器。
通常,以您正在做的方式讓單個(gè)密鑰作為 CA 和作為 TLS 服務(wù)器執(zhí)行雙重職責(zé)是自找麻煩,在這里沒有充分的理由這樣做;雖然 RFC5280 實(shí)際上并沒有禁止這種做法,但它至少似乎不鼓勵(lì)這種做法,除非有特殊情況需要。
但是,就目前而言,您使用 CA 證書的方式在技術(shù)上不符合 RFC5280,因?yàn)樗粋€(gè)擴(kuò)展的密鑰使用擴(kuò)展,僅指定 TLS 客戶端和服務(wù)器身份驗(yàn)證,但您使用它來簽署證書。它可能是寬容的,但在沒有anyExtendedKeyUsage關(guān)鍵目的的情況下x509.CreateCertificate,這里真的應(yīng)該失敗。

TA貢獻(xiàn)1852條經(jīng)驗(yàn) 獲得超1個(gè)贊
該錯(cuò)誤與 X509 證書中存在的 SAN 字段擴(kuò)展有關(guān)。X509 證書中的 SAN 字段可以包含以下類型的條目;
DNS 名稱
IP地址
URI
詳細(xì)信息可以在這里找到
通常在證書驗(yàn)證過程中,可以在某些系統(tǒng)上執(zhí)行 SAN 擴(kuò)展驗(yàn)證。因此,您會(huì)看到這樣的錯(cuò)誤消息
您有兩個(gè)選項(xiàng)可以避免此錯(cuò)誤消息,
在證書中添加 SAN IP 字段
跳過證書驗(yàn)證步驟 [這是您通過注釋掉所做的]

TA貢獻(xiàn)1808條經(jīng)驗(yàn) 獲得超4個(gè)贊
仔細(xì)觀察ncw's gist,我注意到一個(gè)關(guān)鍵的區(qū)別是InsecureSkipVerify客戶端的 TLS 配置中的選項(xiàng)設(shè)置為true. 我添加了這個(gè),所以
client.Transport.(*http.Transport).TLSClientConfig = &tls.Config{
Certificates: []tls.Certificate{deviceCert},
RootCAs: pool,
InsecureSkipVerify: true,
}
現(xiàn)在測試通過了。
服務(wù)器證書的驗(yàn)證超出了這個(gè)測試的范圍,所以這對我的目的來說已經(jīng)足夠了,但我仍然很想知道驗(yàn)證失敗的原因。
- 3 回答
- 0 關(guān)注
- 235 瀏覽
添加回答
舉報(bào)