Google 地圖平台根憑證授權單位遷移常見問題

本文件包含以下章節：

如要進一步瞭解進行中的 Google 根憑證授權單位遷移作業，請參閱「異動簡介」一節。

術語

我們收集您在本文件中需要熟悉的最重要術語，並整理成下方清單。如需更完整的相關術語總覽，請參閱「Google Trust Services 常見問題」一文。

安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 憑證
憑證會將加密編譯金鑰繫結至特定身分。
安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 憑證可用來驗證並建立與網站的安全連線。憑證是由稱為「憑證授權單位」的實體核發並加密簽署。
瀏覽器需要使用信任的憑證授權單位所核發的憑證，才能瞭解傳輸的資訊已傳送至正確的伺服器，且在傳輸過程中經過加密。
安全資料傳輸層 (SSL)
安全資料傳輸層 (SSL) 曾是部署最為廣泛的通訊協定，功用為加密網際網路通訊。一般認為安全資料傳輸層 (SSL) 通訊協定不再安全，因此不建議使用。
傳輸層安全標準 (TLS)
傳輸層安全標準 (TLS) 是安全資料傳輸層 (SSL) 的後續版本。
憑證授權單位 (CA)
憑證授權單位就像是裝置和使用者的數位護照局，可以核發經過加密技術保護的文件 (憑證) 來確認實體 (例如網站) 與其宣告的身分相符。
核發憑證前，憑證授權單位會負責確認憑證中的名稱，是否與提出要求的使用者或實體有關聯。
「憑證授權單位」一詞可指 Google Trust Services 等機構，也可以指核發憑證的系統。
根憑證存放區
根憑證存放區包含應用程式軟體供應商所信任的一組憑證授權單位。大部分網路瀏覽器和作業系統都有專屬的根憑證存放區。
憑證授權單位必須遵守應用程式軟體供應商所訂定的嚴格要求，才可納入根憑證存放區。
這些要求通常包括須符合業界標準，例如憑證授權單位/瀏覽器論壇規定。
根憑證授權單位
根憑證授權單位 (更正確地說，是指其憑證) 為憑證鏈中的最頂層憑證。
根憑證授權單位憑證通常是自行簽署的憑證。與這些憑證相關聯的私密金鑰會儲存在極為安全的設施中，且會維持在離線狀態，以防他人未經授權擅自存取。
中繼憑證授權單位
中繼憑證授權單位 (更正確地說，是指其憑證) 為可用於簽署憑證鏈中其他憑證的憑證。
中繼憑證授權單位主要用於核發線上憑證，同時讓根憑證授權單位憑證能保持離線狀態。
中繼憑證授權單位又稱從屬憑證授權單位。
核發憑證授權單位
核發憑證授權單位 (更正確地說，是指此授權單位的憑證) 為可用於簽署憑證鏈中最底層憑證的憑證。
這個最底層憑證通常稱為訂閱者憑證、終端實體憑證或分葉憑證。在本文件中，我們也會使用「伺服器憑證」一詞。
憑證鏈
憑證會連結至核發者 (由其加密簽署)。憑證鏈是由分葉憑證、所有其核發者憑證和根憑證所組成。
交叉簽署
應用程式軟體供應商的用戶端必須更新根憑證存放區，納入新的憑證授權單位憑證，才能受到自家產品的信任。含有新憑證授權單位憑證的產品需要一些時間，才會廣泛獲得採用。
為了提高與舊版用戶端的相容性，憑證授權單位憑證可由其他先前既有的憑證授權單位「交叉簽署」。這樣就能有效地為同一個身分 (名稱和金鑰組) 建立第二個憑證授權單位憑證。
視根憑證存放區中包含的憑證授權單位而定，用戶端最多會在其信任的根層級建立不同的憑證鏈。

一般資訊

異動簡介

總覽

2017 年，Google 展開為期多年的專案，來核發及使用自家的「根憑證」，也就是加密簽名，這是 HTTPS 採用的傳輸層安全標準 (TLS) 網際網路安全性的基礎。

第一階段完成後，GS Root R2 就能確保 Google 地圖平台服務的傳輸層安全標準 (TLS) 安全性。Google 向 GMO GlobalSign 收購了 GS Root R2 這個具有高知名度且廣受信任的根憑證授權單位，這樣就能更輕鬆轉換至 Google 自家核發的 Google Trust Services (GTS) 根憑證授權單位，。

實際上，所有傳輸層安全標準 (TLS) 用戶端 (例如網路瀏覽器、智慧型手機及應用程式伺服器) 都信任這個根憑證，因此能夠在遷移的第一階段與 Google 地圖平台伺服器建立安全連線。

不過，憑證授權單位可能會「刻意」不核發自身憑證到期時間過後仍有效的憑證。GS Root R2 於 2021 年 12 月 15 日到期，因此 Google 使用自家根憑證授權單位「GTS Root R1」核發的憑證，將相關服務遷移至新的憑證授權單位「GTS Root R1 Cross」。

雖然大多數的新式作業系統和傳輸層安全標準 (TLS) 用戶端程式庫皆已信任 GTS 根憑證授權單位，但為了確保大多數舊版系統的轉換作業都能順利進行，Google 向採用「GlobalSign Root CA - R1」的 GMO GlobalSign 併購了交叉簽署功能。「GlobalSign Root CA - R1」是歷史最悠久、也最受信任的現有根憑證授權單位之一。

因此，大多數客戶的 Google 地圖平台用戶端已認可其中任一受信任的根憑證授權單位 (或兩者皆認可)，而且在遷移的第二階段完全不會受到影響。

這也適用於在 2018 年遷移的第一階段採取行動的客戶，前提是他們當時有遵循我們的操作說明，安裝推薦 Google 根憑證授權單位組合中的所有憑證。

如有下列情況，建議您檢查系統：

  • 您的服務是在非標準或舊版平台上運作，且/或您自行維護根憑證存放區
  • 您並未在 2017 至 2018 年 Google 根憑證授權單位遷移的第一階段採取行動，或者您沒有安裝推薦 Google 根憑證授權單位組合所提供的整組憑證

如果符合上述情況，您可能必須使用建議的根憑證更新用戶端，才能在這個遷移階段順利使用 Google 地圖平台。

請參閱下方的詳細技術說明。如需一般操作說明，請參閱「如何確認我的根憑證存放區是否需要更新」一節。

此外，我們也建議您繼續將根憑證存放區與上方收錄的根憑證授權單位組合保持同步，以便在日後根憑證授權單位有所變更時，確保服務不受影響。不過，如有任何這類變更，我們都會事先公告。請參閱「如何取得有關這個遷移階段的最新消息？」一節和「如何事先收到日後遷移作業的通知？」一節，進一步瞭解如何隨時掌握最新消息。

技術摘要

如 2021 年 3 月 15 日的 Google 安全性網誌所宣布，Google 地圖平台在 2018 年初以來一直使用的根憑證授權單位「GS Root R2」在 2021 年 12 月 15 日到期。因此，Google 會在今年遷移至新核發的憑證授權單位「GTS Root R1 Cross」。這表示我們的服務將逐漸改用這個新憑證授權單位所核發的傳輸層安全標準 (TLS) 分葉憑證。

大多數的新式傳輸層安全標準 (TLS) 用戶端和系統都已預先設定為使用「GTS Root R1」憑證，或是應透過一般軟體更新收到這個憑證，而「GlobalSign Root CA - R1」甚至應能在舊版系統中使用。

不過，如果您同時符合下列兩項條件，則至少應檢查系統：

  • 您的服務是在非標準或舊版平台上運作，且/或您自行維護根憑證存放區
  • 您並未在 2017 至 2018 年 Google 根憑證授權單位遷移的第一階段採取行動，或者您沒有安裝推薦 Google 根憑證授權單位組合所提供的整組憑證

「如何確認我的根憑證存放區是否需要更新」一節提供了一般指引，協助您測試系統是否會受到影響。

詳情請參閱「為何應將我的根憑證存放區與推薦 Google 根憑證授權單位組合保持同步？」這個問題下的說明。

如何取得有關這個遷移階段的最新消息？

在公開問題 186840968 加上星號，即可取得相關最新消息。我們在遷移程序期間，如遇到任何大家可能會有興趣的主題，也會更新這份常見問題清單。

如何事先收到日後遷移作業的通知？

建議您追蹤 Google 安全性網誌。我們也會在網誌發布公告之後，盡快更新產品相關說明文件。

此外，也請您訂閱 Google 地圖平台通知，因為我們會定期在論壇上發布最新消息，協助您掌握可能會影響大量客戶的異動。

我們使用多項 Google 服務，這些服務會受到根憑證授權單位遷移的影響嗎？

會，所有 Google 服務和 API 都將進行根憑證授權單位遷移，但時程可能因服務而異。不過，在確認 Google 地圖平台用戶端應用程式所使用的根憑證存放區，含有推薦 Google 根憑證授權單位組合中列出的所有憑證授權單位後，您的服務應該就不會受到進行中的遷移作業影響；而將這些項目保持同步，可讓您在根憑證授權單位日後有異動時也不會受到影響。

如需進一步的深入分析，請參閱「為何應將我的根憑證存放區與推薦 Google 根憑證授權單位組合保持同步？」和「哪些類型的應用程式會有中斷的風險？」這兩個問題下的說明。

下方「如何確認我的根憑證存放區是否需要更新」一節也提供有關測試系統的一般操作說明。

如何確認我的根憑證存放區是否需要更新

請透過下列測試端點測試您的應用程式環境：

  • 如果能與 GTS Root R1 Cross 測試端點成功建立傳輸層安全標準 (TLS) 連線，您應該就不會受到 GS Root R2 到期問題的影響。
  • 如果能與 GTS Root R1 測試端點成功建立傳輸層安全標準 (TLS) 連線，您的應用程式甚至可能在 2028 年「GTS Root R1 Cross」和「GlobalSign Root CA - R1」到期後仍會受到保護。

只要符合以下條件，您的系統通常就能與這項根憑證授權單位異動相容：

  • 您的服務是在有人維護的主流作業系統上運作，且採用的作業系統和程式庫會持續修補，且您「沒有」自行維護的根憑證存放區；或是
  • 您遵循我們先前的建議，且安裝推薦 Google 根憑證授權單位組合中的所有根憑證授權單位

可能受到影響的客戶應立即安裝推薦 Google 根憑證授權單位組合中的憑證，以免日後服務中斷。

詳情請參閱「為何應將我的根憑證存放區與推薦 Google 根憑證授權單位組合保持同步？」這個問題下的說明。

有什麼簡單的工具可以用來驗證根憑證存放區嗎？

curl 和 openssl 這兩個指令列工具可在調查時派上用場。兩者皆適用於大多數的平台，且提供測試設定的各種選項。

想瞭解如何取得 curl，請參閱下方「取得 curl」一節。

下列 openssl 指令適用於 1.1.1 或更新版本。 我們不再支援 1.1.1 以下版本。如果您使用的是舊版，可以視需要為版本升級或修改這些指令。想瞭解如何取得 openssl，請參閱下方「取得 OpenSSL」一節。

您也可以在下方「我可以在哪裡取得需要的工具？」一節找到更多實用工具。

如需具體測試操作說明，請參閱「如何確認我的根憑證存放區是否需要更新」一節。

測試預設根憑證存放區

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

驗證推薦 Google 根憑證授權單位組合

下載推薦 Google 根憑證授權單位組合，然後按照下列步驟操作：

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Google 根憑證授權單位遷移作業如何繼續？又是在何時？

  1. 第一階段 (遷移至 GS Root R2) 於 2017 年 1 月宣布，在 2017 年下半年展開，並在 2018 年上半年告成。
  2. 第二階段 (遷移至 GTS Root R1 Cross) 於 2021 年 3 月宣布，預計將於未來幾個月內展開，也就是在 2021 年 12 月 15 日 GS Root R2 到期之前。

後續遷移階段的時間表將於憑證未來到期之前盡早宣布。

不過，如果將根憑證存放區與推薦 Google 根憑證授權單位組合中收錄的根憑證授權單位清單保持同步，您的應用程式未來就不會受到影響。

另請參閱「為何應將我的根憑證存放區與推薦 Google 根憑證授權單位組合保持同步？」這個問題下的說明，以取得更多背景資訊。

各項 Google 服務的正式推出計畫

  1. 各項服務將分階段推出，並先從單一資料中心開始。
  2. 接著陸續往外擴大，直到涵蓋全球各地的資料中心。
  3. 如果在任何階段偵測到重大問題，測試作業就會暫時復原，直到問題解決為止。
  4. 根據先前疊代作業的輸入內容，推出時會涵蓋更多 Google 服務，然後再逐步將所有 Google 服務遷移到新憑證。

受影響的對象、時間和區域為何？

隨著新資料中心的遷移，越來越多的 Google 地圖平台開發人員會開始收到新憑證。用戶端要求通常會轉送至地理位置上鄰近資料中心內的伺服器，因此這些變更的影響可能會因本地情況而異。

不過，我們無法預先確認受影響的對象、時間和地點，因此建議所有客戶在可能進行的 Google 根憑證授權單位遷移階段開始以前，盡早驗證自家服務並確認其未來不受影響。

如需進一步的指引，請參閱「如何確認我的根憑證存放區是否需要更新」一節。

注意事項

如果用戶端未設定必要的根憑證，就無法驗證與 Google 地圖平台的傳輸層安全標準 (TLS) 連線。在這種情況下，用戶端通常會發出憑證驗證失敗的警告。

視其傳輸層安全標準 (TLS) 的設定而定，用戶端可能會持續發出 Google 地圖平台要求，也可能拒絕繼續執行要求。

傳輸層安全標準 (TLS) 用戶端與 Google 地圖平台通訊的最低需求為何？

Google 地圖平台憑證採用 DNS 主體別名 (SAN)，因此用戶端的憑證處理功能必須支援包含單一萬用字元做為名稱中最左側標籤的 SAN，例如 *.googleapis.com。

至於其他規定，請參閱「GTS 常見問題」一文中的「傳輸層安全標準 (TLS) 用戶端與 Google 通訊時建議遵守的規定為何？」一節。

哪些類型的應用程式會有中斷的風險？

目前使用系統根憑證存放區，但未執行任何開發人員限制的應用程式

Google 地圖平台網路服務應用程式

如果您使用的是有持續維護且定期更新的主流作業系統 (例如：Ubuntu、Red Hat、Windows 10 或 Server 2019、OS X)，則預設的根憑證存放區中應該已經包含「GTS Root R1」憑證。

如果您使用的是不會再收到更新的舊版作業系統，就不一定會有「GTS Root R1」憑證。不過，您的根憑證存放區很可能會含有「GlobalSign Root CA - R1」，這是歷史最悠久、也最廣受信任的根憑證授權單位之一。

針對直接從使用者裝置呼叫 Google 地圖平台網路服務的行動應用程式，請參閱「行動應用程式是否會有中斷的風險？」這個問題下的指示說明。

用戶端 Google 地圖平台應用程式

一般來說，Maps JavaScript API 應用程式會採用執行應用程式的網路瀏覽器的根憑證。詳情請參閱「JavaScript 應用程式是否會有中斷的風險？」一節。

對於使用任何 Maps SDK for Android、Maps SDK for iOS、Places SDK for Android 或 Places SDK for iOS 的原生行動應用程式，呼叫 Google 地圖平台網路服務的應用程式也適用同樣的規則。

詳情請參閱「行動應用程式是否會有中斷的風險？」這個問題下的說明。

使用自己的憑證組合或採用進階安全性功能 (例如憑證綁定功能) 的應用程式

請務必自行更新憑證組合。如「為何應將我的根憑證存放區與推薦 Google 根憑證授權單位組合保持同步？」這個問題下的說明所述，我們建議您將推薦 Google 根憑證授權單位組合中的所有憑證匯入您自己的根憑證存放區。

如果您要針對應用程式會連線的 Google 網域綁定憑證或公開金鑰，則應將憑證和公開金鑰加進應用程式信任的實體清單中。

有關綁定憑證或公開金鑰的詳細資訊，請參閱「需要更多資訊嗎？」問題下提供的外部資源。

為何應同步處理「根憑證存放區」與「推薦 Google 根憑證授權單位組合」？

推薦 Google 根憑證授權單位組合中的根憑證授權單位清單，已收錄 Google 服務可能於近期採用的所有憑證授權單位。

因此我們極力建議您，先確認根憑證存放區已包含組合中的「所有」憑證，並經常保持兩者同步，確保系統日後不受影響。

如果您的服務是在無人維護的作業系統版本上運作、您基於其他原因而無法持續修補作業系統和程式庫，或是您自行維護根憑證存放區，這一點就格外重要。

請參閱「如何事先收到日後遷移作業的通知？」這個問題下的說明，瞭解如何收到日後根憑證授權單位遷移作業的最新消息。請定期將根憑證存放區與所收錄的清單保持同步，確保服務不會因根憑證授權單位變更而日後發生服務中斷，且在「GTS Root R1 Cross」和「GlobalSign Root CA - R1」到期後仍可繼續運作。

如需進一步的建議，請另外參閱「我正在開發與 Google 服務連線的產品。我需要信任哪些憑證授權單位憑證？」這個問題下的說明 (位於「GTS 常見問題」)。

為何我不應安裝任何分葉或中繼憑證授權單位憑證？

因為這樣當我們註冊新憑證或切換中繼憑證授權單位時，您的應用程式就會有中斷的風險。上述情形可能會在沒有事先通知的情況下隨時發生，且對個人伺服器憑證 (例如 maps.googleapis.com 提供的憑證) 和任何中繼憑證授權單位 (例如「GTS Root R1 Cross」) 同樣都會產生影響。

如要避免您的服務不受這類問題影響，建議只安裝推薦 Google 根憑證授權單位組合中的根憑證，並只使用根憑證來驗證整個錨定憑證鏈的可靠性。

只要根憑證授權單位受到信任，則任何新式傳輸層安全標準 (TLS) 程式庫就能自動驗證這類信任鏈。

JavaScript 應用程式是否會有中斷的風險？

大多數新式瀏覽器都已妥善嵌入並信任 GTS 根憑證，而 GMO GlobalSign 的交叉簽署功能應該可以確保遷移作業能順利完成，即使大多數使用者是用舊版瀏覽器也一樣。其中包含適用於 Maps JavaScript API 的所有官方支援瀏覽器。

每個新式瀏覽器應該都能讓使用者自行驗證 (通常也包含編輯) 瀏覽器所信任的憑證。雖然各瀏覽器的確切位置不盡相同，但憑證清單通常都是在「設定」下方。

行動應用程式是否會有中斷的風險？

如果 Android 和 Apple iOS 裝置會持續收到裝置製造商發布的定期更新，就不需要擔心日後的驗證問題。大多數舊版 Android 手機型號至少包含「GlobalSign Root CA - R1」憑證，但信任的憑證清單可能會因手機製造商、裝置型號和 Android 版本而有所不同。

不過，在 10 以前的 Android 版本中，對 GTS 根憑證授權單位 (包括「GTS Root R1」) 的支援可能仍受限制。

針對 iOS 裝置，Apple 會在自家支援頁面中，提供各個最新 iOS 版本信任的根憑證授權組合清單。不過，所有 iOS 5 以上的版本都會支援「GlobalSign Root CA - R1」。

自 iOS 12.1.3 版起，支援 GTS 根憑證授權單位 (包括「GTS Root R1」)。

詳情請參閱「如何查看手機上信任的根憑證？」這個問題下的說明。

我的瀏覽器或作業系統何時會納入 Google Trust Services 的根憑證？

過去幾年來，Google 與許多主要的第三方進行大量合作，他們負責維護廣受使用和信任的根憑證組合。這些第三方包括作業系統製造商 (例如 Apple 和 Microsoft 及 Google 自家的 Android 和 ChromeOS 團隊)、瀏覽器開發人員 (例如 Mozilla、Apple、Microsoft 及 Google 的 Chrome 團隊)，以及硬體製造商 (例如手機、機上盒、電視、遊戲主機、印表機) 等等。

因此，凡是目前有人維護的系統，都很有可能已經支援 Google 的新版 GTS 根憑證授權單位，包括「GTS Root R1」，而就連舊版系統都很有可能支援「GlobalSign Root CA - R1」；這個憑證授權單位將用於交叉簽署 Google 未來幾年內核發的憑證。

然而，在大多數情況下，第三方憑證的納入時程並非 Google 所能控制，我們只能建議您務必定期套用可用的系統更新。

有些第三方 (例如「Mozilla 的憑證授權單位憑證計畫」) 可能會記錄自己的憑證納入時程表。

疑難排解

我可以在哪裡取得需要的工具？

取得 curl

如果您的作業系統發行版本未提供 curl，則可從 https://curl.haxx.se/ 下載；看您是要下載原始碼並自行編譯工具，或下載預先編譯的二進位檔 (如果有平台可用的檔案) 都可以。

取得 OpenSSL

如果您的作業系統發行版未提供 openssl，請從 https://www.openssl.org/ 下載原始碼並編譯工具。您可以前往 https://www.openssl.org/community/binaries.html 查看第三方建構的二進位檔清單。不過請注意，OpenSSL 團隊並未以任何方式支援這些版本，亦不為其背書。

取得 Wireshark、Tshark 或 Tcpdump

雖然大部分的 Linux 發行版本都提供 wireshark、其指令列工具 tshark 和 tcpdump，但您也可以在 https://www.wireshark.org 取得前兩者適用於其他作業系統的預先編譯版本。

https://www.tcpdump.org 會提供 Tcpdump 和 LibPCAP 的原始碼。

如需這些實用工具的說明文件，請依需求參閱 Wireshark 使用指南、Tshark 手冊頁面和 Tcpdump 手冊頁面。

取得 Java keytool

每個 Java Development Kit (JDK) 或 Java Runtime Environment (JRE) 版本都會隨附 keytool 指令列工具，安裝即可取得 keytool.。不過，除非您是使用 Java 建構應用程式，否則進行根憑證驗證不太可能需要用到 keytool。

如何因應實際執行環境的服務中斷情況

您主要應採取的行動是將推薦 Google 根憑證授權單位組合中的必要根憑證，安裝到應用程式所使用的根憑證存放區。

  1. 與系統管理員合作，升級本機根憑證存放區。
  2. 參閱這份常見問題清單，找出適用您系統的操作說明。
  3. 如果您需要進一步的平台或系統相關協助，請與系統供應商提供的技術支援管道聯絡。
  4. 如需一般協助，請與支援團隊聯絡 (詳情請參閱「與 Google 地圖平台支援團隊聯絡」一節)。 注意：針對平台相關問題，我們只能盡量提供協助。
  5. 在公開問題 186840968 加上星號，即可取得遷移相關最新消息。

與 Google 地圖平台支援團隊聯絡

基本疑難排解

如需一般疑難排解操作說明，請參閱「如何確認我的根憑證存放區是否需要更新」一節。

想知道如何匯入或匯出根憑證，「管理信任的憑證」一節也可能會有一些實用的資訊。

如果問題還是無法解決，而您決定聯絡 Google 地圖平台支援團隊，請備妥以下資訊：

  1. 受影響的伺服器位於哪裡？
  2. 您的服務呼叫哪些 Google IP 位址？
  3. 哪些 API 受到這個問題的影響？
  4. 問題是從何時開始出現 (確切的時間點)？

  5. 下列指令的輸出內容：

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

想瞭解如何取得這些必要工具，請參閱「我可以在哪裡取得需要的工具？」這個問題下的說明。

提交客服案件

請按照 Google 地圖平台支援與資源中的操作說明建立客服案件。

提出客服案件時，除了「基本疑難排解」一節中列的資料，另外還要提供下列資訊：

  • 您的公開 IP 位址為何？
  • DNS 伺服器的公開 IP 位址為何？
  • 如果可以，請擷取傳輸層安全標準 (TLS) 與 https://maps.googleapis.com/ 交涉失敗的 tcpdump 或 Wireshark 封包 (採用 PCAP 格式並以夠大的快照長度來擷取完整封包，不要將封包截斷，例如在舊版 tcpdump 上使用 -s0)。
  • 如果可以，請記錄服務摘錄，並在其中確切指出傳輸層安全標準 (TLS) 連線失敗原因，建議提供完整的伺服器憑證鏈資訊。

想瞭解如何取得這些必要工具，請參閱「我可以在哪裡取得需要的工具？」這個問題下的說明。

公開問題 186840968 的貼文

如要在公開問題 186840968 中張貼留言，請附上基本疑難排解一節中所列的資訊。

如何找出我的 DNS 公開位址？

在 Linux 中，您可以執行以下指令：

dig -t txt o-o.myaddr.l.google.com

在 Windows 中，您可以在互動式模式下使用 nslookup：

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

如何解讀 curl 輸出內容

執行具有 -vvI 旗標的 curl 可產生非常實用的資訊，以下說明如何解讀輸出內容：

  • 以「*」為開頭的程式碼行 - 顯示傳輸層安全標準 (TLS) 交涉的輸出內容及連線終止資訊。
  • 以「>」開頭的程式碼行 - 顯示 curl 傳送的外送 HTTP 要求。
  • 以「<」開頭的程式碼行 - 顯示伺服器傳回的 HTTP 回應。
  • 通訊協定為 HTTPS 時，出現「>」或「<」程式碼行 - 表示傳輸層安全標準 (TLS) 握手成功。

使用傳輸層安全標準 (TLS) 程式庫和根憑證組合

執行具有 -vvI 旗標的 curl 時，也可產生使用的根憑證存放區資訊，但實際的輸出內容可能因系統而異 (如下所示)。

針對 curl 連結 NSS 的 Red Hat Linux 機器，輸出內容會包含下列程式碼行：

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Ubuntu 或 Debian Linux 機器的輸出內容可能包含這些程式碼行：

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

針對使用指定 Google 根憑證 PEM 檔案並含有 --cacert 旗標的 Ubuntu 或 Debian Linux 機器，輸出內容可能包含以下程式碼行：

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

使用者代理程式

外送要求中的「User-Agent」標頭可能會提供有關 curl 和您系統的實用資訊。

Red Hat Linux 機器的範例：

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

傳輸層安全標準 (TLS) 握手失敗

如此程式碼範例所示，程式碼行說明了連線因不受信任的伺服器憑證，而在傳輸層安全標準 (TLS) 握手期間遭到終止。缺少以 > 或 < 開頭的偵錯輸出內容，也是嘗試連線失敗的重要跡象。

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

傳輸層安全標準 (TLS) 握手成功

出現類似此程式碼範例的程式碼行時，代表傳輸層安全標準 (TLS) 握手成功。輸出內容應會列出用於加密連線的加密套件，以及已接受的伺服器憑證的詳細資料。此外，如果有以 > 或 < 開頭的程式碼行，代表系統已成功透過傳輸層安全標準 (TLS) 加密連線，傳輸酬載 HTTP 流量：

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

如何以人類可讀的格式列印收到的伺服器憑證？

假如輸出結果是 PEM 格式 (例如來自 openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 的輸出)，請按照以下步驟列印已提供的憑證：

  • 複製完整的 Base 64 編碼憑證，包含標頭和頁尾：

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • 然後執行下列操作：

    openssl x509 -inform pem -noout -text
````

  • 接著將複製緩衝區的內容貼到終端機。

  • 按下 Return 鍵。

如需輸入和輸出範例，請參閱「如何以人類可讀的格式列印 PEM 憑證」一節。

OpenSSL 中的交叉簽署 Google 憑證看起來會是什麼樣子？

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

管理信任的憑證

如何查看手機上信任的根憑證？

Android 信任的憑證

如「行動應用程式是否會有中斷的風險？」這個問題所述，自 Android 4.0 版起，手機使用者可以驗證「設定」底下所列的信任憑證清單。下表列出確切的「設定」選單路徑：

Android 版本 選單路徑
1.x、2.x、3.x 不適用
4.x、5.x、6.x、7.x 「設定」>「安全性」>「信任的憑證」
8.x、9 「設定」>「安全性與位置資訊」>「加密和憑證」>「信任的憑證」
10+ 「設定」>「安全性」>「進階」>「加密和憑證」>「信任的憑證」

下表按各 Android 版本列出最重要的根憑證可能的適用情況，其以目前可用的 Android 虛擬裝置 (AVD) 系統映像檔進行手動驗證；一旦無法繼續取得系統映像檔，就會改回採用 Android 開放原始碼計畫的憑證授權單位憑證 Git 存放區版本記錄。

Android 版本 GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (2021 年 12 月 15 日前有效)
2.3、3.2、4.x、5.x、6.x、7.x、8.x、9
10+

一般來說，如果不更新韌體或取得裝置的 Root 權限，就無法更新 Android 系統的根憑證存放區。不過，以仍廣為使用的大部分 Android 版本來說，目前的信任根憑證組合可能還可以繼續提供好幾年不中斷的服務，甚至比目前多數現有裝置的生命週期更長。

從版本 7.0 開始，Android 可讓應用程式開發人員透過安全的方式，只新增受其應用程式信任的憑證。方法是綁定憑證與應用程式，並建立自訂的網路安全性設定，詳情請參閱 Android 安全性與隱私權最佳做法「網路安全性設定」訓練說明文件。

不過，如果是來自 Google Play 服務 APK 的流量，第三方應用程式開發人員就無法影響其網路安全性設定，因此這只能算是局部性的因應做法。

在舊版裝置上，您唯一可以採用的選項是由使用者新增的憑證授權單位 (包括將公司群組政策套用至使用者裝置時安裝的憑證授權單位，或由使用者自行安裝的憑證授權單位)。

iOS 信任存放區

雖然 Apple 並未直接對手機使用者顯示預設的信任根憑證組合，但該公司在下列 Apple 支援文章中針對 iOS 5 以上的版本提供信任根憑證授權單位組合的連結：

不過在 iOS 裝置上安裝的其他憑證，都會顯示在「設置」>「一般」>「設定檔」下方。如果未安裝其他憑證，「設定檔」選單可能就不會顯示。

下表根據上述來源，按各 iOS 版本列出最重要根憑證的可用情形：

iOS 版本 GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (2021 年 12 月 15 日前有效)
5、6、7、8、9、10、11、12.0
12.1.3+

我的系統根憑證會存放在哪裡？如何更新？

預設根憑證存放區的位置視作業系統以及使用的安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 程式庫而有所不同。但是在大部分的 Linux 發行版本中，您可以在下列其中一個路徑中找到預設的根憑證：

  • /usr/local/share/ca-certificates：Debian、Ubuntu、較舊的 RHEL 和 CentOS 版本
  • /etc/pki/ca-trust/source/anchors 和 /usr/share/pki/ca-trust-source：Fedora、較新的 RHEL 和 CentOS 版本
  • /var/lib/ca-certificates：OpenSUSE

其他憑證路徑可能包括：

  • /etc/ssl/certs：Debian、Ubuntu
  • /etc/pki/tls/certs：RHEL、CentOS

這些目錄中有某些憑證可能是指向其他目錄中的檔案的符號連結。

OpenSSL 根憑證存放區

針對使用 OpenSSL 的應用程式，您可以透過下列指令查看已安裝元件的設定位置，包括預設的根憑證存放區：

openssl version -d

這個指令會輸出 OPENSSLDIR，其對應至程式庫的頂層目錄，而您可在下方找到程式庫設定：

OPENSSLDIR: "/usr/lib/ssl"

根憑證存放區位於 certs 子目錄中。

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

如果 OpenSSL 和上述範例一樣，都採用預設的系統根憑證存放區，請參閱最上方「我的系統根憑證會存放在哪裡？如何更新？」一節，確保系統根憑證組合是最新版本。

想瞭解如何取得 openssl，請參閱「取得 OpenSSL」一節。

Java 根憑證存放區

Java 應用程式可能會使用自己專屬的根憑證存放區，在 Linux 系統中通常位於 /etc/pki/java/cacerts 或 /usr/share/ca-certificates-java，且可使用 Java keytool 指令列工具加以管理。

如要將個別憑證匯入 Java 憑證存放區，請發出下列指令：

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

只要將 cert.pem 換成各個建議根憑證的對應憑證檔案，將 alias 換成不重複但有意義的憑證別名，以及將 certs.jks 換成您環境中使用的憑證資料庫檔案。

詳情請參閱下列 Oracle 和 Stack Overflow 文章：

Mozilla NSS 根憑證存放區

根據預設，使用 Mozilla NSS 的應用程式也可能使用全系統層級的憑證資料庫 (通常位於 /etc/pki/nssdb 底下，或 ${HOME}/.pki/nssdb 底下使用者專屬的預設存放區)。

如要更新 NSS 資料庫，請使用 certutil 工具。

如要將個別憑證檔案匯入 NSS 資料庫，請發出下列指令：

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

只要將 cert.pem 換成各個建議根憑證的對應憑證檔案，將 cert-name 換成有意義的憑證暱稱，以及將 certdir 換成您環境中使用的憑證資料庫路徑。

詳情請參閱官方的 NSS 工具 certutil 手冊，以及您的作業系統說明文件。

Microsoft .NET 根憑證存放區

Windows .NET 開發人員在下列 Microsoft 文章中，也可找到與更新根憑證存放區有關的實用資訊：

憑證檔案格式

什麼是 PEM 檔案？

隱私強化郵件 (PEM) 實際上是一種用於儲存和傳送加密編譯憑證、金鑰的標準文字檔案格式，制式標準格式為 RFC 7468。

雖然檔案格式是人類可讀的格式，但 Base64 編碼的二進位檔憑證資料不是。不過，PEM 規格允許在文字編碼的憑證內文之前或之後，插入說明文字。很多工具都採用此模式，針對憑證中最相關的資料元素，以明文提供摘要說明。

像 openssl 這類工具也可用來解碼憑證，將整個憑證轉換成人類可讀的格式。詳情請參閱「如何以人類可讀的格式列印 PEM 憑證」一節。

什麼是「.crt」檔案？

允許以 PEM 格式匯出憑證的工具，通常會採用「.crt」副檔名來指出該檔案使用了文字編碼功能。

什麼是 DER 檔案？

唯一編碼規則 (DER) 是編碼憑證的標準二進位格式。PEM 檔案中的憑證通常是 Base64 編碼的 DER 憑證。

什麼是「.cer」檔案？

具有「.cer」字尾的匯出檔案可能會包含 PEM 編碼的憑證，但比較常見的是二進位的 DER 編碼憑證。根據慣例，「.cer」檔案通常只包含單一憑證。

我的系統拒絕匯入來自 roots.pem 的所有憑證

有些系統 (例如 Java keytool) 只能從 PEM 檔案匯入單一憑證 (即使該檔案包含多個憑證)。請參閱「如何從 roots.pem 擷取個別憑證？」這個常見問題下的說明，瞭解如何先分割這類檔案。

如何從 roots.pem 擷取個別憑證？

您可以使用下列簡單的 bash 指令碼，將 roots.pem 分割為其元件憑證：

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

這樣就能建立一些類似此處所列項目的個別 PEM 檔案：

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

接著，可將個別 PEM 檔案 (例如 02265526.pem) 分別匯入，或進一步轉換為憑證存放區可接受的檔案格式。

我系統支援的格式和 PEM 檔案如何互相轉換？

OpenSSL 工具包的指令列工具 openssl 可用來相互轉換各種常用的憑證檔案格式。以下提供如何從 PEM 檔案轉換為常用憑證檔案格式的操作說明。

如需可用選項的完整清單，請參閱官方提供的 OpenSSL 指令列公用程式說明文件。

想瞭解如何取得 openssl，請參閱「取得 OpenSSL」一節。

如何將 PEM 檔案轉換為 DER 格式？

您可以使用 openssl 發出以下指令，將檔案從 PEM 轉換為 DER：

openssl x509 -in roots.pem -outform der -out roots.der
如何將 PEM 檔案轉換為 PKCS #7？

您可以使用 openssl 發出以下指令，將檔案從 PEM 轉換成 PKCS #7：

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
如何將 PEM 檔案轉換為 PKCS #12 (PFX)？

您可以使用 openssl 發出以下指令，將檔案從 PEM 轉換成 PKCS #12：

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

建立 PKCS #12 封存時，您必須提供檔案密碼；如果不打算立即將 PKCS #12 檔案匯入系統，請務必妥善保管密碼。

從根憑證存放區中列出、列印及匯出憑證

如何將 Java Key Store 中的憑證匯出為 PEM 檔案？

您可以使用 keytool 來發出以下指令，列出憑證存放區中的所有憑證，以及可用來匯出每個憑證的別名：

keytool -v -list -keystore certs.jks

只要將 certs.jks 換成您環境中使用的憑證資料庫檔案。這個指令也會顯示每個憑證的別名；如要匯出憑證，您需要使用這個別名。

如要以 PEM 格式匯出個別憑證，請發出下列指令：

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

只要將 certs.jks 換成您環境中使用的憑證資料庫檔案，並提供與您要匯出的憑證對應的 alias 和 alias.pem。

詳情請參閱 Java 平台、標準版工具參考資料：keytool 手冊。

如何將 NSS 根憑證存放區中的憑證匯出為 PEM 檔案？

您可以使用 certutil 來發出以下指令，列出憑證存放區中的所有憑證，以及可用來匯出每個憑證的暱稱：

certutil -L -d certdir

只要將 certdir 換成您環境中使用的憑證資料庫路徑。這個指令也會顯示每個憑證的暱稱；如要匯出憑證，您需要使用這個暱稱。

如要以 PEM 格式匯出個別憑證，請發出下列指令：

certutil -L -n cert-name -a -d certdir > cert.pem

只要將 certdir 換成您環境中使用的憑證資料庫路徑，並提供待匯出憑證對應的 cert-name 和 cert.pem。

詳情請參閱官方的 NSS 工具 certutil 手冊，以及您的作業系統說明文件。

如何以人類可讀的格式列印 PEM 憑證

在下列範例中，我們假設 GTS_Root_R1.pem 檔案已包含下列內容：

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
使用 OpenSSL 列印憑證檔案

發出指令

openssl x509 -in GTS_Root_R1.pem -text

應該會輸出類似這樣的結果：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

想瞭解如何取得 openssl，請參閱「取得 OpenSSL」一節。

使用 Java keytool 列印憑證

發出以下指令

keytool -printcert -file GTS_Root_R1.pem

應該會輸出類似這樣的結果：

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

想瞭解如何取得 keytool，請參閱「取得 Java keytool」一節。

如何查看我的根憑證存放區目前已安裝哪些憑證？

這要取決於您使用的作業系統，以及安全資料傳輸層 (SSL)/傳輸層安全標準 (TLS) 程式庫。不過，能讓您在根憑證存放區之間匯入和匯出憑證的工具，通常也會提供可列出已安裝憑證的選項。

此外，如果您已成功將信任的根憑證匯出至 PEM 檔案，或是您的根憑證存放區已包含儲存的 PEM 檔案，則可嘗試透過任何文字編輯器開啟該檔案 (因為其為純文字檔案格式)。

PEM 檔案可能已加上適當的標籤，並以人類可讀的格式提供相關憑證授權單位 (例如推薦 Google 根憑證授權單位組合) 的資訊：

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

這個檔案也可能只包含憑證部分。在這類情況下，檔案的名稱 (例如 GTS_Root_R1.pem) 可能會描述憑證所屬的憑證授權單位。針對每個憑證授權單位，-----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 權杖之間的憑證字串都不重複。

不過，即使您缺少上述工具，推薦 Google 根憑證授權單位組合中的每個憑證均已加上適當的標籤，因此您可以使用 Issuer 或比較 PEM 檔案憑證字串，放心比對組合與根憑證存放區中的根憑證授權單位。

網路瀏覽器可使用自己的根憑證存放區，也可以使用作業系統提供的預設根憑證存放區。不過，所有新式瀏覽器都應該讓您能管理或至少查看所信任的根憑證授權單位組合。詳情請參閱「JavaScript 應用程式是否會有中斷的風險？」這個問題下的說明。

如需適用手機的操作說明，請另外參閱「如何查看手機上信任的根憑證？」這個問題下的說明。

附錄

需要更多資訊嗎？

請務必參閱您的作業系統說明文件、應用程式程式設計語言的說明文件，以及應用程式使用的任何外部程式庫的說明文件。

任何其他來源的資訊 (包括這份常見問題清單) 可能已經過時或有誤，不應單純仰賴這些資訊。不過，您還是可以在很多 Stack Exchange 問與答社群，以及 AdamW on Linux and more 和 confirm blog 等網站，找到實用的相關資訊。

另請參閱 Google Trust Service 常見問題。

如想進一步瞭解相關進階主題 (例如綁定憑證)，不妨參考 Open Web Application Security Project (OWASP)「憑證和公開金鑰綁定」一文和「綁定一覽表」提供的實用資訊。如需適用 Android 的操作說明，請參閱官方 Android 安全性與隱私權最佳做法「透過 HTTPS 和安全資料傳輸層 (SSL) 確保安全性」訓練說明文件。有關憑證使用及在 Android 綁定公開金鑰的討論，請參閱 Matthew Dolan 的網誌文章「Android 安全性：綁定安全資料傳輸層 (SSL)」，其中可能有您需要的資訊。

Android 安全性與隱私權最佳做法「網路安全性設定」訓練說明文件，以及 JeroenHD 網誌文章「Android 7 Nougat 和憑證授權單位」，則進一步說明如何在 Android 管理其他信任憑證。

如需 Android 開放原始碼計畫信任的根憑證授權單位完整清單，請參閱 CA 憑證 Git 存放區。至於其他以非官方 Android 分支為基礎的版本 (例如 LineageOS)，請存取作業系統廠商提供的適用存放區。