SSL/TLS 是網路上最廣為使用的密碼編譯通訊協定。從技術上來說，TLS 是 SSL 的後繼者，但這兩個詞有時會互通使用，就像這份文件一樣。
傳輸層安全標準 (TLS) 可用於加密透過網路傳送的資訊，確保用戶端與伺服器或負載平衡器之間的隱私權。使用 SSL 的應用程式負載平衡器或 Proxy 網路負載平衡器，至少需要一個私密金鑰和 SSL 憑證。
Trusted Cloud憑證設定方法
如果是使用目標 HTTPS Proxy 的應用程式負載平衡器，負載平衡器的目標 Proxy 必須參照 1 到 15 個Compute Engine SSL 憑證。每個 Compute Engine SSL 憑證資源都包含私密金鑰、對應的憑證，以及 (選用) CA 憑證。
負載平衡器支援
下表列出各負載平衡器支援的憑證設定方法。
| 負載平衡器 | 憑證設定方法：目標 Proxy 參照... | |||
|---|---|---|---|---|
| Compute Engine SSL 憑證 | Certificate Manager 憑證對應關係 | 直接使用 Certificate Manager 憑證 | ||
| 應用程式負載平衡器 (目標 HTTPS Proxy) | ||||
| 區域性外部應用程式負載平衡器 | 支援區域憑證 自行管理 Google 代管 |
自行管理 Google 管理 |
||
| 區域性內部應用程式負載平衡器 | 支援區域憑證 自行管理 Google 代管 |
自行管理 Google 管理 |
||
憑證類型
您可以為負載平衡器建立自行管理的 SSL 憑證。
自行管理的 SSL 憑證
自行管理的 SSL 憑證是指您自行取得、佈建及更新的憑證。自行管理的憑證可以是下列任何一種公開金鑰憑證類型：
- 網域驗證 (DV)
- 機構驗證 (OV)
- 延伸驗證 (EV) 憑證
您可以使用 Compute Engine SSL 憑證資源建立自行管理的 SSL 憑證。詳情請參閱「使用自行管理的 SSL 憑證」。
支援的金鑰類型
區域性自行管理的 Compute Engine SSL 憑證支援下列金鑰類型：
- RSA-2048
- RSA-3072
- RSA-4096
- ECDSA P-256
- ECDSA P-384
使用含 ECDSA 金鑰的憑證
本節將探討為何我們建議使用 ECDSA 而非 RSA，做為憑證簽署金鑰的最佳做法。
要使用的金鑰類型
對於大多數 TLS 憑證，建議選擇 ECDSA P-256 金鑰類型，因為這類金鑰提供強大的密碼安全防護，簽署作業效能優異，且能有效運用網路頻寬。
使用其他憑證金鑰類型的原因可能如下：
- 如果您需要支援不支援 ECDSA 憑證的舊版用戶端，除了 ECDSA P-256 憑證外，也可以提供 RSA-2048 憑證。
- 如有特定法規遵循需求，必須使用較大的金鑰大小或特定金鑰類型，則可使用 ECDSA P-384、RSA-2048、RSA-3072 和 RSA-4096 金鑰。
為什麼要選擇 ECDSA 而非 RSA
相較於 RSA，ECDSA 的主要優勢在於能以小得多的金鑰，提供同等的密碼編譯安全等級。這項效率可轉換為實質的效能和資源效益。金鑰較小並不代表安全性較弱，因為 ECDSA 是以橢圓曲線離散對數問題為基礎，可為每個金鑰單元提供更強大的安全性，且在某些情況下，運算效率也比 RSA 更高。
例如：
- 256 位元 ECDSA 金鑰提供的安全等級與 RSA-3072 金鑰類似。
- 384 位元的 ECDSA 金鑰提供的安全等級，高於任何廣泛支援的 RSA 金鑰大小。
ECDSA 的主要優點：
效能：與提供同等安全等級的 RSA 作業相比，ECDSA 簽署作業的運算密集程度明顯較低。這可減少 CPU 負載和延遲時間，對於高輸送量或對延遲時間敏感的系統而言至關重要。
效率：較小的金鑰和簽章需要的頻寬和儲存空間較少，這對資源受限的環境 (例如行動裝置和物聯網裝置) 特別有利。
多個 SSL 憑證
應用程式負載平衡器的目標 Proxy 最多可參照 15 個 Compute Engine SSL 憑證。第一個參照的 Compute Engine SSL 憑證資源，是目標 Proxy 的預設 (主要) 憑證。
詳情請參閱負載平衡說明文件中的「目標 Proxy」和「SSL 憑證」。
憑證選取程序
如果負載平衡器的目標 Proxy 參照多個 Compute Engine SSL 憑證，系統會依下列程序選取憑證。
用戶端連線至負載平衡器後，用戶端和負載平衡器會協商 TLS 工作階段。在 TLS 工作階段交涉期間，用戶端會將支援的 TLS 密碼清單傳送給負載平衡器 (位於 ClientHello 中)。負載平衡器會選取公開金鑰演算法與用戶端相容的憑證。用戶端也可以在交涉過程中，將伺服器名稱指示 (SNI) 主機名稱傳送至負載平衡器。有時，負載平衡器會使用 SNI 主機名稱資料，選取要傳送給用戶端的憑證。
如果負載平衡器的目標 Proxy 只參照一個憑證，系統就會使用該憑證，而用戶端傳送的 SNI 主機名稱值則無關緊要。
如果負載平衡器的目標 Proxy 參照兩個以上的憑證，負載平衡器會使用下列程序選取單一憑證：
如果用戶端未在
ClientHello中傳送任何 SNI 主機名稱，負載平衡器會使用憑證清單中的第一個憑證。如果用戶端傳送的 SNI 主機名稱與任何憑證的通用名稱 (CN) 不符，且與任何憑證的主體別名 (SAN) 不符，負載平衡器就會使用憑證清單中的第一個憑證。
在所有其他情況下，負載平衡器會使用下列比對程序選取憑證：
系統會根據一般名稱 (CN) 和主體別名 (SAN) 憑證屬性，比對最長後置字串，並優先選取 ECDSA 憑證，而非 RSA 憑證。
為說明比對方法，請考慮參照下列兩個憑證的目標 Proxy：
憑證 A
- CN：
cats.pets.example.com - SAN：
cats.pets.example.com、*.pets.example.com、*.example.com
- CN：
憑證 B
- CN：
dogs.pets.example.com - SAN：
dogs.pets.example.com、*.pets.example.com、*.example.com
- CN：
現在請考慮下列情境：
- 如果用戶端傳送的 SNI 主機名稱為
cats.pets.example.com，負載平衡器會使用憑證 A。 - 如果用戶端傳送的 SNI 主機名稱為
ferrets.pets.example.com，由於沒有完全相符的憑證，負載平衡器會選取其中一個憑證 (憑證 A 或憑證 B)，因為兩者的 SAN 清單都包含*.pets.example.com。在這種情況下，您無法控制選取的憑證。
- 如果用戶端傳送的 SNI 主機名稱為
選取憑證後，負載平衡器會僅在所選憑證使用的公開金鑰演算法與用戶端在
ClientHello中傳送的密碼相容時，將該憑證傳送給用戶端。如果用戶端不支援包含負載平衡器所選憑證公開金鑰演算法 (ECDSA 或 RSA) 的密碼套件，TLS 交涉就會失敗。