沒有預先共享的公鑰就不可能進行身份驗證
如果我錯了，請糾正我，數字證書要求使用者在其 Web 瀏覽器中擁有證書的公鑰，對嗎？
這意味著它必須是預先共享的。
（假設我正在設計一個密碼系統，它是一個使用 TLS 的加密聊天應用程序。但是，我希望密碼系統是端到端的，這意味著客戶端必須直接連接到他們選擇的伺服器。
如果我允許我的客戶創建自己的伺服器以進行直接端到端加密，我如何才能使這個密碼系統的身份驗證工作？換句話說，應用程序不包含數字證書的預共享公鑰。
在這種情況下，我的應用程序是否注定沒有預共享的公鑰？
您不需要公鑰/證書出現在瀏覽器中。您只需要設計一種方法來確保對等方提供的公鑰/證書是有效的。在 Web 瀏覽器場景中，這通常由簽署這些證書的許多已知 CA 完成。但是您也可以要求使用者通過指紋或在您信任的中央目錄中註冊證書來驗證證書。
您也可以使用所謂的“首次使用信任”，它基本上是“安裝此證書”。這有一個人在中間攻擊的一次性風險。這就是今天大部分時間使用 SSH 的方式。
您甚至不需要已知/經過驗證的證書，而是可以使用匿名密鑰協議。這當然有一個大問題，即每次進行此密鑰交換時，中間的人都可以欺騙伺服器。TLS 對此有 aDH 密碼。
最後，您也可以使用基於共享密碼的 TLS。這取決於雙方是否相互認識，是否可以在帶外實際驗證對方。
如果您沒有中央目錄授權，最常用的方法是使用首次使用信任設置以及手動驗證對等方的附加選項（例如，除了電話的弱身份證明之外，這也用於 Whats App數字）。
如果我錯了，請糾正我，數字證書要求使用者在其 Web 瀏覽器中擁有證書的公鑰，對嗎？
你錯了，但在某種程度上你是間接正確的。您錯了，因為瀏覽器不需要為站點證書提供預共享的公鑰。該站點將連同響應一起發送其證書，該證書將由證書頒發機構(CA) 簽名，該證書也附有證書。
這就轉移了問題——只要伺服器證書的 CA 簽名簽出，現在瀏覽器就必須檢查 CA 證書的真實性。通常它本身是由另一個CA 簽名的，這將問題轉移了一層。這稱為證書鏈。
您的作業系統或瀏覽器供應商捆綁了一組根證書，並且每個證書鏈都必須以其中一個證書結尾，您的瀏覽器才能將其辨識為真實的。因此，正如您所懷疑的，一些預共享的公鑰是必要的，但您不需要與您訪問的站點安排預共享的公鑰。（相反，您需要信任證書頒發機構和您的作業系統或瀏覽器供應商，這有其自身的一系列問題。）
如果我允許我的客戶創建自己的伺服器以進行直接端到端加密，我如何才能使這個密碼系統的身份驗證工作？
您需要按照以下方式做一些事情：
- 為您的應用程序創建 CA。任何一個：
- 一個獨立的，在這種情況下，您必須將根證書與您的應用程序捆綁在一起。（在這種情況下，這個證書的私鑰就是王國的鑰匙，需要用偏執的熱情加以保護。）
- 由您的客戶認可的第三方認證的證書（例如，證書捆綁在他們的作業系統或瀏覽器中）。
- 讓客戶私下生成他們的密鑰對和相關證書，並安全地送出後者供您的 CA 簽名。（這是一個潛在的弱點——安全地驗證客戶端在這里至關重要！）
- 客戶現在可以使用他們的簽名證書與他們的對等方建立經過身份驗證的端到端加密會話。
一些閱讀可以幫助您入門，但您需要閱讀的不僅僅是這兩個連結：