這是一個帶有 TLS 協議的 Tomcat 謎題（我已經在 Tomcat 使用者列表伺服器上找到了它）
我有一個在 Amazon Linux EC2 Linux 實例上執行的 Tomcat 8.5 伺服器。Tomcat 在埠 8443 上執行，IPTables 將 443 重新映射到它。
我已更改連接器的“sslProtocol”子句以指定 TLS 1.2 協議。並且更改不起作用：它仍然接受 TLS 1.0 和 1.1 以及 1.2。有人知道問題可能是什麼嗎？
連接器如下所示（敏感資訊已編輯）：
<Connector port="8443" proxyPort="443" protocol="org.apache.coyote.http11.Http11NioProtocol" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json" maxThreads="1000" socket.appReadBufSize="1024" socket.appWriteBufSize="1024" bufferSize="1024" SSLEnabled="true" scheme="https" secure="true" keystoreFile="/etc/tomcat8/dev.REDACTED.net.ks" keyAlias="REDACTED" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" clientAuth="false" sslProtocol="TLSv1.2" />（以前，“sslProtocol”子句是 ‘sslProtocol=“TLS”’）
相同的“sslProtocol”子句在客戶的 AS/400 上執行的 Tomcat 7 伺服器的連接器標記中工作得很好，將其限制為 TLS 1.2。
正確的答案是在周末從 Tomcat 使用者列表中直接從兩個開發人員那裡得到的：
sslEnabledProtocols=“TLSv1.2”
來自Connector 的文件（格式簡化，因為在 Stack 上做 HTML 太難了）
sslProtocol 這是 SSLHostConfig 元素的 sslProtocol 屬性的別名，其 hostName 為default。如果未明確定義此 SSLHostConfig 元素，則會創建它。
對於 SSLHostConfig（同上）
僅 sslProtocol JSSE。要使用的 SSL 協議（單個值可以啟用多個協議 - 有關詳細資訊，請參閱 JVM 文件）。如果未指定，則預設為 TLS。在創建 SSLContext 實例（例如 Oracle Java 7）時，可以從 JVM 文件中獲取算法的允許值。注意：此屬性和協議之間存在重疊。
換句話說，這是傳遞給 的值
SSLContext.getInstance()。由於您不辨識您的 Java，因此我將使用目前 Oracle LTS 版本 11 的上下文名稱（已添加重點）：TLSv1.2 支持 RFC 5246：TLS 版本 1.2；可能支持其他 SSL/TLS 版本
SunJSSE 提供程序中該上下文的實現啟用了 TLSv1（意味著 1.0）、TLSv1.1 和 TLSv1.2——換句話說，它意味著“最大1.2”。在舊版本的 Java 中，它還啟用了 SSLv3，但在幾年前 POODLE 攻擊之後，它被認為不安全而被刪除。（我喜歡說“POODLE 攻擊”，聽起來很傻。:-)
選擇性地控制已啟用協議列表的屬性
protocols在 SSLHostConfig 中——在上面的引用中（簡要地）提到——或者sslEnabledProtocols在 Connector 中等效但拼寫不同。在舊版本中（在 8.5“合併”配置之前），它僅在使用 OpenSSL/APR 時SSLProtocol位於連接器中。相同的“sslProtocol”子句在客戶的 AS/400 上執行的 Tomcat 7 伺服器的連接器標記中工作得很好，將其限制為 TLS 1.2。
AS/400 幾乎肯定使用的是IBM Java，而不是 Sun-now-Oracle-now-OpenJDK。IBM 早在很久以前就從 Sun 獲得了原始碼許可，並保證與 Sun 定義的 Java 規範兼容——該規范明確排除了加密提供者，現在仍然如此。IBM 有自己的加密提供程序，它們與 Sun/Oracle/Open 的不同（儘管在功能上非常相似），因此要了解它對特定 SSLContext 的作用，您需要在（或某些）IBM 網站上找到 IBM 文件，其中我總是覺得無法導航。它可以將 TLSv1.2 實現為“最低1.2”。
PS：您的密鑰庫中是否真的同時擁有 RSA和ECC 證書？如果不是，那麼您用於密碼的巨大價值中的大部分都是無用的，浪費的混亂。另外，任何地方都沒有理智的客戶想要使用靜態 ECDH（或靜態 DH）密碼套件。您了解 TLS 術語中 ECDH 和 ECDHE 之間非常重要的區別嗎？