多個 TLS 函式庫對 X.509 Name Constraints 的實作各說各話
oss-security · 2026-10-14
RFC 5280 的 Name Constraints 本該讓上層 CA 限定下層憑證只能簽哪些名稱，但多個主流 TLS 函式庫對大小寫、IP、URI、萬用字元的判斷並不一致，同一張憑證在 A 函式庫通過、在 B 函式庫被拒。
研究者 Oleh Konko（1seal）於 2026-10-14 在 oss-security 彙整各家修補狀態，CERT/CC 同時發布 VU#573195 等弱點說明。該貼文自述不公布新的 CVE，內容是整理已公開的修補與尚在處理的回報。
原本的問題
Name Constraints 是私有 PKI、service mesh 與企業內部 CA 常用的限縮手段：根或中繼 CA 宣告 permittedSubtrees 或 excludedSubtrees，驗證端必須拒絕超出範圍的葉憑證。問題在於 RFC 對不少情境沒有明文規定，各實作只好自行解讀，結果出現落差。
依 CERT/CC 的說明，落差主要有四類：
- DNS 大小寫：RFC 5280 要求不分大小寫比對，GnuTLS 在回報時對部分名稱做了區分大小寫的比較（
CVE-2026-3833，3.8.13 修正）。 - IP 位址：RFC 定義了 IPv4 與 IPv6 各自的編碼，卻沒說 IPv4-mapped IPv6 是否等同 IPv4，部分函式庫視為不同，限制其中一種形式時另一種可能不受約束。
- URI authority：RFC 3986 允許 host 前有 userinfo，遇到
@、冒號、query 或 fragment 時，各家抽出的 host 不同。OpenSSL 已合併 PR #30319 處理@出現在 path、query 或 fragment 的情況，但另一則 userinfo 冒號的回報不在該修補範圍內。 - 萬用字元：RFC 5280 沒有定義萬用字元 SAN 的語意，LibreSSL 與 wolfSSL（PR #9991）都有相關回報。
代表案例：pyca/cryptography
GHSA-m959-cc7f-wv43（CVE-2026-34073）說明得最清楚。該函式庫只拿 DNS 限制去檢查子憑證裡的 SAN，沒有檢查正在驗證的對端名稱。
葉憑證 SAN: *.example.com
上層 CA 限制: excluded = bar.example.com
對端名稱: bar.example.com
舊行為: 通過（限制只比對 SAN，不比對對端名稱）
修補後 46.0.6: 拒絕（對端名稱若當作 SAN 會違反限制，就拒絕）受影響版本為 46.0.5 以前，修補版為 46.0.6。該 advisory 標為 Low，並指出要利用必須有 Web PKI 通常避開的少見拓撲。
各函式庫修補狀態
| 函式庫 | 識別碼 | 修補版本 |
|---|---|---|
| pyca/cryptography | CVE-2026-34073 | 46.0.6 |
| rustls/webpki | CVE-2026-93601、CVE-2026-93600 | 0.103.12（excludedSubtrees 情況於 0.103.13） |
| GnuTLS | CVE-2026-3833 | 3.8.13 |
| wolfSSL | CVE-2026-5263 | 5.9.1 |
| Go crypto/x509 | CVE-2026-33810 | Go 1.26.2 |
| AWS-LC | GHSA-3jrg-j22w-mpmc 等 | 1.71.0 |
貼文另列出仍在分流、遭爭議或被拒的項目：Go 有兩則在分流，OpenSSL 的 userinfo 冒號回報在分流，NSS 與 LibreSSL 仍在協調，Mbed TLS 認為屬功能需求而非弱點。貼文自己也提醒，其中一個 wolfSSL 的 CVE 編號與該 CVE 實際描述的內容（ALPN 解析）對不上，引用前應回頭核對 CERT/CC 與廠商公告。
影響範圍
CERT/CC 明確寫出利用條件：攻擊者必須取得對所選憑證欄位的有效簽章、驗證路徑必須可達、應用程式還要拿被接受的身分去做授權。它同時指出「驗證器之間的不一致本身不構成被利用」，目前也沒有已知的實際利用。
真正需要檢查的是這幾類環境：
- 用 Name Constraints 限縮內部 CA 或外部合作 CA 的私有 PKI，而且信任它簽出的憑證。
- service mesh、CDN、企業 PKI 中混用多種 TLS 函式庫，同一張憑證在不同元件得到不同結果，而憑證本身簽章有效，很難偵測。
- 把驗證通過的名稱直接拿去做存取授權的服務。
修補與緩解
貼文唯一提出的緩解是升級到上表版本，也沒有公布未修補問題的測試向量。CERT/CC 另建議：用實際部署需求測試所用驗證器、葉憑證只使用明確列出的 SAN、搭配簽發政策與應用層白名單。多放一個驗證器只有在輸入相同且失敗即拒絕時才有幫助。
CERT/CC 的廠商欄位顯示，Go、Apple、OpenSSL、LibreSSL、pyca、wolfSSL 的狀態都還是 Unknown，且尚無廠商聲明。盤點時請以各家自己的 advisory 為準。
原始來源：oss-security 貼文、CERT/CC VU#573195、pyca GHSA-m959-cc7f-wv43