政府憑證如何使用於 CDN 之說明

說明

透過使用 CDN 能提升性能與安全性，並搭配使用政府自己的憑證增加信任、合規與自主掌控，適合敏感數據與法律要求等情境。

以下使用資安院監控系統作為示範展示。系統部署於 GCP 的虛擬機（VM），並透過 Cloud Load Balancing 將後端指向該 VM 進行流量分發。

若要搭配 Cloud CDN 使用外部原站，建議參考文件 External backends specified by using internet NEGs 進行設置

注意事項

GCP 掛載憑證方式是在 Cloud Load Balancing 服務上關聯 Load Balancer ，並且可以於 Load Balancer 上前端設定 HTTP/2 及 HTTP/3。
AWS Certificate Manager（ACM）僅允許 ACM 本身或其他信任的 certificate authority (CA) 單位，其支援如 Mozilla 信認之 CA，目前政府憑證入口網尚未於列於 Mozilla 信任 CA 清單，需要匯入完整 TLS 憑證串鍊（根憑證及中繼憑證）才能使用。

參考資料：

AWS Certificate Manager (ACM) 匯入ACM憑證的先決條件

以 GCP 為例

設定步驟

於政府憑證入口網申請憑證。取得私鑰（含私鑰密碼）及憑證，憑證更新可以於政府憑證入口網檢視下載。

將憑證使用以下 openssl 命令轉換為 pem 格式。

$ openssl x509 -inform der -in 405DB92C677DA6AAD09F96A139842C42.cer -out hc-cert-2024.pem

GCP Certificate Manager 須使用已解密私鑰，使用以下 openssl 命令將加密私鑰解密並匯出。

指令：

$ openssl rsa -in ./hc.nics.nat.gov.tw_server.key -out ./hc.nics.nat.gov.tw_server-without-password.key

輸出結果：

Enter pass phrase for ./hc.nics.nat.gov.tw_server.key:
writing RSA key

至政府憑證入口網下載 GTLSCA 憑證串鍊，解壓縮後取得三個檔案
- 根憑證 ROOTeCA_64.crt
- 中繼憑證 eCA1_to_eCA2-New.crt
- GTLSCA.crt
將憑證內文、根憑證及中繼憑證，依序合併至同一個檔案。注意：憑證內文必須為全檔案第一個排序。

$ cat hc-cert-2024.pem > hc-cert-2024-full.pem
$ cat ./GTLSCA_All/*.crt >> hc-cert-2024-full.pem

於 GCP Certificate Manager 建立新的憑證
- Name：命名您的新的憑證於 GCP Certificate Manager
- Create mode：選擇「Upload my certificate」
- Certificate：複製步驟 5 所產生包含根憑證、中繼憑證、憑證內文 pem 檔案內文
- Private key：複製步驟 3 所產生已解密私 key 檔案內文

選定 GCP Cloud Load Balancing 服務合適 Load Balancer 並建立。

請參考 Set up a classic Application Load Balancer with a managed instance group backend。
監測工具使用 Application Load Balancer，以下於 Application Load Balancer 更新 Frontend configuration 頁面，選擇步驟 4 新建立之憑證。

Application Load Balancer 更新 Backend configuration 頁面，選擇勾選「Enable Cloud CDN」並設定對應 Cache mode。

檢視步驟

使用 Firefox 瀏覽器確認使用 HTTP/2 協議。

確認憑證為「政府伺服器數位憑證管理中心」所發放。

以 AWS 為例

設定步驟

開啟 AWS Certificate Manager 服務於 us-east-1 地區。因 AWS CloudFront 屬於 Global 服務，若需要掛載憑證需要於 us-east-1 建立 Certificate。
將憑證使用以下 openssl 命令轉換為 pem 格式。

$ openssl x509 -inform der -in 405DB92C677DA6AAD09F96A139842C42.cer -out hc-cert-2024.pem

使用以下 openssl 命令將加密私鑰解密並匯出。

指令：

$ openssl rsa -in ./hc.nics.nat.gov.tw_server.key -out ./hc.nics.nat.gov.tw_server-without-password.key

輸出結果：

Enter pass phrase for ./hc.nics.nat.gov.tw_server.key:
writing RSA key

於 AWS Certificate Manager 控制台點選「Import」
- Certificate body：複製步驟 2 所產生 pem 檔案內文
- Certificate Private key：複製步驟 3 所產生已解密私 key 檔案內文
- Certificate chain：至政府憑證入口網下載 GTLSCA 憑證串鍊，並三個檔案（根憑證ROOTeCA_64.crt 及中繼憑證 eCA1_to_eCA2-New.crt、GTLSCA.crt）內文複製至欄位內。

增加 tag （選用）

匯入

至 AWS CloudFront 控制台，點選「Create distribution」

AWS CloudFront 有諸多設定，以下擷圖主要以 TLS 憑證及 HTTP/2（或 HTTP/3）設定展示為主。
- Origin 設定您的原站域名
  - 在此為示範測試，僅作為驗證使用 hc.nics.nat.gov.tw。一般來說，建議設定原站域名
- 於 Settings 段落選擇
  - Custom SSL certificate 選擇步驟 4-6 建立憑證
  - Alternate domain name（CNAME）：新增 CNAME，因此範例為 hc.nics.nat.gov.tw 網站，故新增 hc.nics.nat.gov.tw
  - Supported HTTP versions：勾選啟用「HTTP/2」及「HTTP/3」

檢視步驟

因 hc.nics.nat.gov.tw 建制於 GCP 上，並未將 CNAME 指向於 CloudFront 所產生的 domain，以下使用 openssl 命令檢視 CloudFront 關聯 TLS 憑證是否正確。

指令：

$ openssl s_client -showcerts -connect divxxxxxxjm0.cloudfront.net:443 -servername hc.nics.nat.gov.tw </dev/null

輸出結果：

CONNECTED(00000003)
depth=3 C = TW, O = "Chunghwa Telecom Co., Ltd.", OU = ePKI Root Certification Authority
verify return:1
depth=2 C = TW, O = "Chunghwa Telecom Co., Ltd.", CN = ePKI Root Certification Authority - G2
verify return:1
depth=1 C = TW, O = \E8\A1\8C\E6\94\BF\E9\99\A2, CN = \E6\94\BF\E5\BA\9C\E4\BC\BA\E6\9C\8D\E5\99\A8\E6\95\B8\E4\BD\8D\E6\86\91\E8\AD\89\E7\AE\A1\E7\90\86\E4\B8\AD\E5\BF\83 - G1
verify return:1
depth=0 C = TW, L = \E8\87\BA\E7\81\A3, O = \E8\A1\8C\E6\94\BF\E9\99\A2-\E6\95\B8\E4\BD\8D\E7\99\BC\E5\B1\95\E9\83\A8-\E6\95\B8\E4\BD\8D\E6\94\BF\E5\BA\9C\E5\8F\B8, CN = hc.nics.nat.gov.tw
verify return:1
---
Certificate chain

...
-----END CERTIFICATE-----
 1 s:C = TW, O = "Chunghwa Telecom Co., Ltd.", CN = ePKI Root Certification Authority - G2
   i:C = TW, O = "Chunghwa Telecom Co., Ltd.", OU = ePKI Root Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov 17 08:51:35 2015 GMT; NotAfter: Dec 20 02:31:27 2034 GMT
-----BEGIN CERTIFICATE-----

...
-----END CERTIFICATE-----
 2 s:C = TW, O = \E8\A1\8C\E6\94\BF\E9\99\A2, CN = \E6\94\BF\E5\BA\9C\E4\BC\BA\E6\9C\8D\E5\99\A8\E6\95\B8\E4\BD\8D\E6\86\91\E8\AD\89\E7\AE\A1\E7\90\86\E4\B8\AD\E5\BF\83 - G1
   i:C = TW, O = "Chunghwa Telecom Co., Ltd.", CN = ePKI Root Certification Authority - G2
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 19 06:46:45 2019 GMT; NotAfter: Aug 19 06:46:45 2031 GMT
-----BEGIN CERTIFICATE-----

...
-----END CERTIFICATE-----
 3 s:C = TW, O = "Chunghwa Telecom Co., Ltd.", OU = ePKI Root Certification Authority
   i:C = TW, O = "Chunghwa Telecom Co., Ltd.", OU = ePKI Root Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA1
   v:NotBefore: Dec 20 02:31:27 2004 GMT; NotAfter: Dec 20 02:31:27 2034 GMT
-----BEGIN CERTIFICATE-----

...
---
Server certificate
subject=C = TW, L = \E8\87\BA\E7\81\A3, O = \E8\A1\8C\E6\94\BF\E9\99\A2-\E6\95\B8\E4\BD\8D\E7\99\BC\E5\B1\95\E9\83\A8-\E6\95\B8\E4\BD\8D\E6\94\BF\E5\BA\9C\E5\8F\B8, CN = hc.nics.nat.gov.tw
issuer=C = TW, O = \E8\A1\8C\E6\94\BF\E9\99\A2, CN = \E6\94\BF\E5\BA\9C\E4\BC\BA\E6\9C\8D\E5\99\A8\E6\95\B8\E4\BD\8D\E6\86\91\E8\AD\89\E7\AE\A1\E7\90\86\E4\B8\AD\E5\BF\83 - G1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 7741 bytes and written 386 bytes
Verification: OK
---

回報建議

說明​

注意事項​

以 GCP 為例​

設定步驟​

檢視步驟​

以 AWS 為例​

設定步驟​

檢視步驟​

說明

注意事項

以 GCP 為例

設定步驟

檢視步驟

以 AWS 為例

設定步驟

檢視步驟