Encryption
X509 轉換為加密和簽名密鑰
我們有專有工具，它採用 p12 文件並生成 .key 文件。在密鑰文件中，我看到兩個 PEM 格式的部分：加密證書和簽名證書。當我在我的機器上打開它們時，它們具有相同的 CN、Expiration 和 Issuer 等。這個密鑰文件用於雙向驗證，我們將密鑰文件提供給客戶端。
這裡發生了什麼？我了解您和客戶交換公鑰並信任它們的正常相互身份驗證，但是為什麼需要實現此方法？
通常認為使用相同的密鑰進行加密和簽名是一種不好的做法，這意味著一個節點（使用者、伺服器等）將有兩個密鑰對：一個用於簽署內容（公鑰用於驗證）和一個解密內容（公鑰用於加密）。因此，如果您希望在這種情況下為兩方進行完全身份驗證和加密的通信，您將需要 4 個密鑰對（通信雙方各有兩個）。
由於兼容性，在某些情況下可能需要將密鑰導出到*.key*文件中，但它會帶走證書的屬性及其法律約束力（因為密鑰可能在沒有任何直接通知的情況下被篡改）。
閱讀您的評論後，我將專注於每個證書的重點。為此，假設您是一家銀行的客戶。從您的角度來看，您可能有興趣實現身份驗證+完整性/機密性或兩者兼而有之。例如：
- 您進入他們的網頁以獲取電話號碼的名稱：您需要知道該號碼是正確的並且屬於他們，因此期望驗證與網頁關聯的簽名是有意義的，因此您不會得到被騙了。需要伺服器簽名
- 您向銀行發送匿名投訴：您只需要使用銀行的公鑰對消息進行加密。需要對伺服器進行加密
- 您想登錄您的網上銀行並查看資訊：您需要確保資訊來自銀行（簽名），並且您發送的資訊只能被銀行讀取（加密）。你需要這兩項任務。
請注意，此時，尚未提供有關您作為客戶的證書或個人資訊。您可以使用自己的一對證書（例如，在實踐中由智能卡輔助），或者在大多數情況下，使用較弱的身份驗證方法（密碼、密碼+一次性密碼等）。在後一種情況下，可以通過僅在伺服器端的兩個證書的中介來創建受信任的會話。
因此，如您所見，您可以定義具有 1、2、3 或 4 個證書的方案，具體取決於特定要求和其他安全控制的可用性。但是，在伺服器之間使用 4 個證書的情況似乎更合理。