我使用T.Rob的建議來調試Websphere MQ服務器和客戶端之間的SSL錯誤，並需要幫助瞭解SSL握手（SSL connect to MQ using .net mq client SSLV3?）。Websphere MQ服務器和客戶端之間的SSL/TLS握手
我WMQ 7.5客戶端應用程序是C代碼，並使用密鑰庫（名.kdb）。使用WebSphere管理員提供的CHLTAB。 WMQ服務器正在運行Java，並且通道被定義爲相互認證。
該文章指出，在SSL/TLS握手中，服務器總是發送其公共證書以響應連接請求。然後，客戶必須首先檢查簽名和有效日期，然後在其信任庫中查找簽署證書的東西，以驗證該證書。
這是我的困惑：由於我在客戶端的密鑰庫只有應用程序的個人證書，客戶端如何驗證服務器發送的公共證書？我已將我的應用程序證書的通用名稱提供給WebSphere服務器管理員，但僅此而已。
預先感謝澄清！
關於「我的客戶端上的密鑰庫僅在應用程序的個人證書」的位，令人擔憂。這是行不通的。客戶端KDB 必須有有服務器的公鑰。如果MQ服務器具有SSLCAUTH(OPTIONAL)，則服務器的公共證書是KDB中所需的全部功能，以使連接成功。
TLS握手的第一部分是在客戶端驗證服務器的證書。公鑰/私鑰對的使用是如何保證對方事物的真實性。爲了發生這種情況，服務器必須擁有自己的個人證書，並且客戶端必須擁有簽署者鏈根的公鑰。對於自簽證書，個人證書的公開部分必須由客戶信任。對於CA簽名的證書，CA Root必須受到客戶端的信任。它是哪一個，用來簽署服務器的個人證書客戶必須信任的東西，或者證書不能被驗證。
TLS握手是對稱的，所以第二部分與第一部分完全相同，但角色相反。因此，在啓用雙向身份驗證的情況下，客戶端必須擁有自己的個人證書（因爲該證書包含私鑰），並且服務器必須信任與客戶端匹配的公鑰的任何簽名。如果客戶證書是自簽名的，QMgr必須信任它。如果客戶的證書是CA簽名的，QMgr必須信任簽名者。無論哪種方式，QMgr必須有一個證書來驗證客戶端的KDB。
遵循此邏輯，對於匿名客戶端連接，所需的部分是QMgr密鑰庫中的個人證書（因爲它包含QMgr的私鑰）以及客戶端KDB或Java Trust Trust中匹配的可信證書。這些都不是可選的。
如果要對客戶端進行身份驗證，則仍然需要與匿名客戶端相同的兩個證書，因爲握手部分必須在客戶端通過身份驗證之前完成。此外，現在你還需要在客戶端擁有自己的個人證書（因爲它包含了客戶端的私鑰）和QMGR現在需要信任任何簽署了客戶端證書 - 客戶端證書如果自簽名或簽名的根，如果CA -籤。
作爲一個方面說明，也有在後一些混亂，因爲它說，「我的WMQ 7.5客戶端應用程序是C代碼和WMQ服務器運行Java。」在服務器端使用Java的隊列管理器中沒有任何內容。有些Java組件可以用來管理JNDI對象並運行示例代碼。在現代MQ版本中，Java運行Web控制檯。但QMgr本身沒有Java組件，傳入通道連接請求的路徑中沒有Java組件。 QMgr的聽衆，代理商和其他內部流程都受到了限制。因此，我不能確定那裏提到的是什麼，除了在MQ服務器端運行的Java以及參與TLS握手的概念可能是該帖子中提到的一些混淆的來源。 ;-)
謝謝T.Rob的詳細解釋。使用MQ管理員，我們已經成功地通過步驟1和2調試SSL連接。在步驟3，用SRVCONN通道設置爲SSLCAUTH（必填）我的客戶端應用程序觸發了以下錯誤： –
下面是來自客戶端應用程序觸發錯誤（運行用C語言編寫的Linux V7.5）： AMQ9654：無效的SSL證書是從遠程系統收到的。 我重建了.kdb並插入了一個SHA256證書（由Venafi創建）。想知道MQ服務器通道上指定的CypherSpec類型（TLS_RSA_WITH_AES_128_CBC_SHA256）是否存在兼容性問題？ –
除非您在通道上使用橢圓曲線密碼，否則該證書應該起作用。由於不清楚所看到的錯誤是在客戶端還是在服務器端，但是假設這是一個QMgr錯誤，聽起來像您可能需要在客戶端上走簽署者鏈，以確保服務器擁有正確的可信簽名者。此外，在更新KDB之後，您在QMgr上執行了「刷新安全類型（SSL）」或重新啓動它，對吧？ –
您客戶端的密鑰庫有個人證書。個人證書是一對密鑰。有公共部分和私人部分。公共部分可以用來驗證服務器的信任。 – Alaine