在 java 中，我們有 javax.net.ssl.SSLContext.getDefault()，它被描述為：回傳默認的 SSL 背景關系。
這讓我思考以下問題：
何時創建默認 SSL 背景關系？這是否僅在呼叫 setDefault(SSLContext context) 時發生？我們通過 -Djavax.net.ssl.keyStore=mykeystore.jks 的情況呢？是否基于此密鑰庫創建了默認的 ssl 背景關系？在像Tomcat這樣的服務器環境的情況下會發生什么？Tomcat 是否根據 keystoreFile="/keystore/tomcatkeystore.jks 中的配置設定默認 ssl 背景關系？
當我們嘗試使用任何 https 端點時，使用的是默認背景關系嗎？
在處理需要不同密鑰庫/配置集的安全連接時，我們能否在不影響已為默認 ssl 背景關系配置的內容的情況下創建新的 SSL 背景關系？
謝謝你的幫助。
uj5u.com熱心網友回復：
何時創建默認 SSL 背景關系？這是否僅在呼叫 setDefault(SSLContext context) 時發生？
不。如果您使用setDefault（IME 非常罕見），您需要區分默認的兩個“級別”：
回傳的物件
.getDefault——這可以稱為“當前默認值”。它可以通過.setDefault在這種情況下控制物件集及其創建來設定，也可以自動創建，請參見下一步。在
.getDefault沒有預先設定值的情況下呼叫時自動和內部創建的物件。這可以稱為“創建的默認值”，或者“默認默認值”（！）一旦創建，這個物件就被設定為默認值，所以第二次呼叫.getDefault回到第一個專案符號下。
大多數程式不使用，.setDefault所以如果他們根本不使用.getDefault（他們可能不使用），那么第一個呼叫轉到第二個專案符號，隨后呼叫第一個專案符號。
Note.getDefault被許多庫、平臺和中間件隱式呼叫，因此您不能假設僅僅因為您沒有撰寫這樣的呼叫它就不會發生（并且可能會呼叫第二個專案符號）。
我們通過 -Djavax.net.ssl.keyStore=mykeystore.jks 的情況呢？是否基于此密鑰庫創建了默認的 ssl 背景關系？
在第二個專案符號中 - 當您不設定默認值并且默認值會自動創建時，是的。更確切地說，“創建的默認值”使用 sysprops javax.net.ssl.keyStore* 和 ...trustStore* 如果設定；如果不是，則默認信任庫為檔案 JRE/lib/security/cacerts（或 jssecacerts，如果存在，這種情況很少見），密鑰庫為 none/empty。
如果您明確設定默認值，則您可以控制其中的內容；如果您愿意，您可以使用這些 sysprops。
Tomcat 是否根據 keystoreFile="/keystore/tomcatkeystore.jks 中的配置設定默認 ssl 背景關系？
不。它設定了一個背景關系（可能有多個）用于處理傳入的 HTTPS 連接，但那不是（或那些不是）默認背景關系。
當我們嘗試使用任何 https 端點時，使用的是默認背景關系嗎？
也許。有數以千計的方法可以“使用... https”，而且它們都可以不同。其中一些可能總是使用默認背景關系；許多人有時會使用默認值，有時不會；有些人可能永遠不會使用默認值。如果沒有更具體的問題，就不可能說出來。
在處理需要不同密鑰庫/配置集的安全連接時，我們能否在不影響已為默認 ssl 背景關系配置的內容的情況下創建新的 SSL 背景關系？
絕對可以，而這正是您應該做的。請注意，一些連接方法使用SSLContext直接，而一些（大多為與非SSL / TLS連接的詳細兼容）使用一個[SSL]SocketFactory或[SSL]ServerSocketFactory從創建并鏈接到SSLContext。這些實作相同的結果，但您的代碼略有不同。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/331230.html
上一篇：HyperledgerFabric：使用FabricGatewayJavaSDK的TLS內部錯誤
下一篇：Go模板后處理：有可能嗎？