技術上可以發出完全通配的SSL證書嗎？

我想獲得*的SSL證書。也就是說，對於任何領域。這個想法是用自定義CA證書籤名，在目標設備上安裝該CA證書，並使用該設備連接到基於IP的地址（例如https://192.168.1.123）。沒有可用的DNS，並且地址可能每次都有所不同。目標設備上的瀏覽器應該沒有警告地工作，但是隻有當通配符證書由已知CA（這是我們的自定義CA，其證書已安裝在設備上）簽名時纔會工作，以防止任何可能的MITM攻擊。技術上可以發出完全通配的SSL證書嗎？

瀏覽器會理解這樣的通配符證書嗎？是否有任何其他解決方法可以允許使用瀏覽器連接到任意的基於IP的SSL服務器而無需警告並且同時具有MITM保護（假設可以自定義客戶端CA列表）？

來源

2014-02-10 dragonroot

如果您能夠將CA添加到目標設備，爲什麼您無法調整該設備上的DNS以知道源服務器的地址？這通常與修改'/ etc/hosts'或本地等價物一樣簡單。 – SingleNegationElimination

這個問題似乎是脫離主題，因爲它不是關於編程。 –

是的，有通配符證書。您可以諮詢SSL證書提供商以獲取更多詳細信息。我懷疑這是否可以基於IP

來源

2014-02-10 17:16:37

雖然公鑰基礎結構已損壞，但並非如此，您將獲得*的證書和瀏覽器會接受它。相關的RFC是RFC2818，如果你閱讀它，你會看到瀏覽器接受*.example.com和www*.example.com，但不是www.*.example.com,www.*.com甚至*。

來源

2014-02-10 17:57:26

HTTPS有兩個關於證書身份驗證的規範：RFC 2818 (the HTTPS specification itself) Section 3.1和RFC 6125（更新的RFC試圖協調如何完成任何協議）。

至於我可以解釋RFC 2818，它並不禁止這樣做（但我想這不會考慮使用情況的話）：

名稱可以包含通配符字符*這被認爲匹配任何單個域名組件或組件碎片。例如，.a.com與foo.a.com匹配，但是不是bar.foo.a.com。 f .com與foo.com匹配，但不匹配bar.com。

RFC 6125通常不鼓勵使用完全通配符證書（section 7.2），並只允許它在原理上最左邊的標籤（section 6.4.3）。這或多或少意味着應該有多個標籤。

有一個additional errata for RFC 6125 on the subject：「RFC6125錯誤：通配符證證書的檢查沒有在呈現標識多少標籤規格」：

還要注意這個問題引出的是能夠確定什麼的問題構成所謂的域名「公共後綴」（例如「.com」，「.co.uk」） - 我們不能簡單地寫入規範「通配符必須在最左邊的標籤位置並且在那裏必須在通配符的右側至少有一個「兩個」三個「標籤」。

除了規格之外，這在實踐中不大可能奏效。任何商業CA都不應該發佈其中的一個。他們偶爾會犯錯誤，但希望沒有那麼愚蠢。您可以通過部署自己的CA（或者在您批准的MITM代理中使用本地自動CA）來實現此目的。即使是這樣，一些客戶也會拒絕驗證這些證書。例如，Chromium even forbids *.com or *.co.uk。

請注意，在這兩種情況下，通配符都用於DNS名稱，而不是IP地址。無論如何，如果您願意，獲得*的證書將無法用於您的用例。也許尋找替代DNS解決方案（例如mDNS）能夠使用名稱可能會有所幫助。

來源

2014-02-11 13:23:32 Bruno

技術上可以發出完全通配的SSL證書嗎？

回答

相關問題