我知道現在客戶端和伺服器之間存在協商...但是是什麼決定瞭如何伺服器選擇回應 https 請求時將使用的 TLS 版本？例如，它如何將連線限制為最低版本的 TLS？另外，伺服器使用的安全性憑證和伺服器使用的 TLS 版本之間是否存在關係？我正在閱讀一些 AWS 文檔，它似乎表明了這一點。
這裡完全是新手；如果這是錯誤的詢問，請道歉。我不介意一個連結來閱讀，作為答案。
答案1
但是，什麼決定了伺服器在回應 https 請求時如何選擇將使用的 TLS 版本？
在 TLS 握手中，客戶端向伺服器宣布它可以執行的最佳版本。如果伺服器支援的協定版本等於或小於客戶端版本，它將以其中最好的版本回應。如果伺服器不支援這些，握手將會失敗。如果伺服器回覆客戶端不支援的版本，握手也會失敗。
另外，伺服器使用的安全性憑證和伺服器使用的 TLS 版本之間是否存在關係？
TLS協定版本和使用的憑證之間幾乎沒有關係。早已過時的 SSLv3 和協定的 TLS 1.x 版本之間存在細微差別，因為只有 TLS 1.x 支援擴充。一個重要的擴展是server_name（SNI - 伺服器名稱指示)，其中客戶端指定它想要到達的域。如果在同一 IP 位址上有多個證書，伺服器可以選擇適當的證書。
答案2
我不是 TLS 協議握手協商專家，所以這裡是一個“粗略”的答案（專家，如果我錯了請糾正我）*我在這裡只談論 TLS 版本。不是密碼。
場景 1：您的客戶端將嘗試可以使用的最高版本的 TLS。假設您的客戶端支援 1.1（舊）和 1.2。然後，伺服器將使用盡可能高的版本連接您。希望是1.2。
情境 2：您的用戶端支援 1.2 或更高版本，而您的伺服器是一台舊的且未更新的機器，只了解 1.1。
場景 3：與 2 相同，但方向相反。連接也行不通。
您的客戶端將無法協商連線。它會停在那裡。
場景 4：您的客戶端以及伺服器都支援版本 1.1 和 1.2，但假設伺服器管理員配置（假設 Apache HTTPD）強制僅使用 1.2 進行連接，那麼您的客戶端將使用 1.2。
另外，還有 TLS 1.3......但這將是相同的心態。