SSL/TLS是一種看似簡單的技術。它易於部署，正常部署後就可以運行了。但想要部署地安全可靠卻並非易事。這就使得系統管理員和開發者不得不花費額外時間和精力了解SSL/TLS相關技術，以便能配置一個高安全的服務器或應用。

為了讓系統管理員輕鬆部署安全站點或應用，本篇將講解SSL/TLS部署最佳實踐。

一、私鑰和證書

在SSL/TLS中，所有安全都始於服務器的密碼標識。因此需要一個強大的私鑰來防止攻擊。另外，擁有一張有效且強大的證書也是至關重要的，它能授予私鑰代表特定主機名的權利。沒有這兩個基本構建塊，任何東西都無法得到安全保障。

1.1使用2048位私鑰

對於大多數網站來說，2048位RSA密鑰足以保障其安全性了。RSA加密算法的普遍應用使得這種類型的密鑰成為默認的安全選擇。如果是2048位，這類密鑰提供了相當於112位的安全性。如果您想要比這更高的安全性，如128位的安全性，您需要3072位的RSA密鑰，但是RSA加密算法的擴展性不太好，3072位的RSA密鑰將會影響性能。ECDSA密鑰提供了一種替代方案，可以給予更高的安全性和更好的性能。ECDSA密鑰為256位，提供128位的安全性。少數老舊的客戶端不支持ECDSA，但現代客戶端能支持。如果您不介意管理此類設置的開銷，則可以同時部署支持RSA和ECDSA加密算法的SSL證書。

1.2保護私鑰

私鑰是非常重要的資產之一，需限制訪問私鑰人數，同時建議您採取以下策略保護私鑰：

在可信的計算機上生成私鑰，建議拒絕CA為您生成私鑰。
從一開始就對密鑰進行安全保護，防止密鑰存儲在備份系統中時遭到破壞。
證書被破壞後，撤銷舊證書並生成新的私鑰。
每年更新SSL證書。如果您採用自動化管理證書，更新頻率應更高。有效期較短的證書在實踐中更安全。
保持證書的公鑰與私鑰相匹配，否則每當您獲得新證書時，還應該生成新的私鑰。

1.3確保覆蓋所有域名

確保您的SSL證書覆蓋您希望用於所有站點域名，否則無效證書警告會降低用戶對該站點的信任度。經驗法則是，安全的Web服務器應該具備這樣一個證書，該證書對於指向它的每個DNS名稱都有效。

通配符證書有其用途而且能滿足更廣泛的需求，但在跨團隊或部門情況下，使用通配符證書時容易將密鑰暴露給很多人。為控制訪問私鑰人數防止私鑰被濫用，這種情況下請避免使用通配符證書。

請確保將所有必要的域名添加到使用者可選名稱(SAN)，因為所有最新的瀏覽器都不會通過檢查通用名稱進行驗證。

1.4從可信CA獲取證書

選擇認真對待其證書業務和安全性的可信證書頒發機構，即CA。選擇 CA 時，請參考以下標準：

對待安全的態度。所有 CA 都會接受定期審計，但有些CA比其他CA更重視安全。找出在這方面哪個CA做的更好並不容易，但您可以做的一項是檢查他們的安全歷史記錄，查看CA面對漏洞的反應是怎樣，是否從錯誤中吸取了教訓。
提供的服務。您選擇的CA應支持證書吊銷列表 (CRL) 和在線證書狀態協議 (OCSP) 吊銷方法，並具有穩定的網絡可用性和高性能。許多站點喜歡使用域名驗證型DV證書，但您還應該考站點是否需要擴展驗證型EV證書。但無論哪種情況，您都應該選擇公鑰算法。目前大多數網站都使用RSA算法，但ECDSA可能會因為其性能優勢在未來變得重要。
證書管理。如果您需要大量SSL證書並在複雜的環境中運行，請選擇一個可以為您提供良好的管理工具的CA。

注意：為獲得最佳效果，請提前至少一周獲取證書，以便部署並正常運行。這樣做有助於避免因計算機時間不準確而導致出現證書不安全警告。另外，由於CA需要額外的時間才能有效的將新證書發送給OCSP響應，所以最好先提前獲取證書避免證書撤銷檢查的失敗。因此，千萬不要等到您的證書到期時才替換它們。

1.5使用強簽名算法

證書安全性取決於私鑰的強度和簽名中使用的散列函數強度。如今SHA1散列函數的證書被普遍認為是不安全的，所以最好安裝使用SHA256散列函數的證書。

1.6使用DNS CAA

DNS CAA是一項防止HTTPS證書錯誤頒發的安全措施，CAA標準可以允許域名所有者限制能為其域名頒發證書的CA。如果沒有CAA記錄，那麼任何人都能為該域名生成CSR並獲取任何CA簽發的證書。使用DNS CAA記錄，可以減少欺詐證書的出現，從而使站點更加安全。如果CA啟用自動簽發證書的流程，那麼就應該檢查DNS CAA記錄，這樣可以減少錯誤頒發證書的風險。

建議通過為您的證書添加CAA記錄將CA列入白名單。添加您信任的CA為您頒發證書。

二、配置

正確的SSL服務器配置可以讓您的網站身份能正常向用戶展示以增強信任，並能使用安全的加密原語以緩解所有已知的缺陷。

2.1使用完整的證書鏈

在部署SSL證書時，僅靠服務器證書是不夠的，這就需要兩個或多個證書來建立完整的信任鏈。如果您部署了一個有效證書，但卻缺少必要的中間證書，那麼就會出現常見的配置問題。為避免這種情況的發生，您需要按相應順序部署CA提供給您的所有證書。

2.2使用安全的協議

SSL/TLS 系列中有六種協議：SSL 2.0、SSL 3.0、TLS1.0、TLS 1.1、TLS 1.2 和 TLS 1.3：

SSL 2.0不安全，不能使用。
SSL 3.0與HTTP一起使用時不安全。它也已過時，建議不使用。
TLS 1.0和TLS 1.1已於2020年1月棄用。
TLS 1.2 和TLS 1.3都沒有已知的安全問題。TLS 1.2或TLS 1.3是目前主要使用的安全協議，因為這些版本提供現代認證加密（也稱為AEAD）。如果您的服務器不支持 TLS 1.2或TLS 1.3，那您的網站可能缺乏安全性。
TLS 1.3相對來說更加安全，性能更強大。

2.3使用安全的密碼套件

要確保安全通信，必須首先確定您是直接與所需方通信（而不是通過竊聽的其他人）並安全地交換數據。在 SSL 和 TLS 中，密碼套件定義了安全通信的發生方式。它們由不同的構建塊組成，其理念是通過多樣性實現安全。如果發現其中一個構建塊薄弱或不安全，您應該能夠切換到另一個構建塊。

目前主要依賴提供強身份驗證和密鑰交換、前向保密和至少128位加密的AEAD套件。可能仍然有支持其他一些較弱的套件，前提是它們僅與不支持任何更好的舊客戶端協商。下面是一些過時的密碼原語，建議不要使用：

ADH套件不提供身份驗證。
NULL密碼套件不提供加密。
導出密碼套件在連接中協商時不安全，但也可以針對更喜歡更強大的套件（FREAK攻擊）的服務器使用。
弱密碼（112 位或更少位數）的套件很容易被破解，是不安全的。
RC4不安全。
64 位分組密碼（3DES / DES / RC2 / IDEA）很弱。
RSA密鑰交換密碼套件較弱。

建議使用AEAD或PFS密碼套件：

AEAD密碼套件-包括CHACHA20_POLY1305, GCM and CCM。
PFS密碼套件-包括ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1和所有的TLS 1.3密碼。

以下是專為RSA和ECDSA密鑰設計的套件配置：

注意：建議先在臨時環境中測試TLS配置，只有在確定一切按預期工作時才轉移到生成環境。請注意，以上是一個通用列表，並非所有系統（尤其是舊系統）都支持所有套件，所以建議參考《SSL服務器配置評級指南》進行檢測。

以上示例配置使用標準的TLS套件名稱。一些平台使用非標準名稱；有關更多詳細信息，請參閱您平台的文檔。例如，以下套件名稱將與OpenSSL一起使用：

2.4選擇最佳密碼套件

在 SSL 3.0 及更高版本的協議中，客戶端需提交他們支持的密碼套件列表，服務器從列表中選擇一個用於連接的套件。然而，並非所有服務器都能做出最佳選擇。有些服務器會從客戶端列表中選擇第一個支持的套件。因此，讓服務器主動選擇最佳可用密碼套件才能使SSL部署安全達到最佳化。

2.5使用前向保密

前向保密（也稱完美前向保密，簡稱PFS），它是一種協議功能，可不依賴於服務器私鑰實現安全對話。如果不使用前向保密的密碼套件，他人就能恢復服務器私鑰，進而解密所有先前記錄下來加密對話。使用ECDHE套件就能在Web瀏覽器中啟用前向保密。為了支持更廣泛的客戶端，您還應該使用 DHE套件作為ECDHE後備。除非絕對必要，請避免RSA密鑰交換。

2.6使用強密鑰交換

對於密鑰交換，公共站點通常可以選擇常用的Diffie-Hellman密鑰交換(DHE)或橢圓曲線變體ECDHE。RSA密鑰交換應用非常廣泛，但它不提供前向保密。當然還有其他密鑰交換算法，但它們通常不安全。

2015年，一組研究人員發表了針對DHE的新攻擊，他們的工作被稱為Logjam攻擊。研究人員發現，較低強度的DH密鑰交換（例如768位）很容易被破解。為了安全起見，如果部署 DHE，請至少配置2048位。一些老版本的客戶端（例如Java 6）可能不支持這種強度級別。ECDHE相比之下性能更高、更快速。secp256r1命名曲線（也稱為P-256）是一個不錯的選擇。