在 Front Door (傳統) 自訂網域上設定 HTTPS
重要
Azure Front Door（傳統版）將於 2027 年 3 月 31 日淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前將 Azure Front Door （傳統） 配置檔移轉至 Azure Front Door Standard 或 進階版 層。 如需詳細資訊，請參閱 Azure Front Door（傳統版）淘汰。
本文會示範如何為與前端主機區段下 Front Door (傳統) 建立關聯的自訂網域啟用 HTTPS 通訊協定。 若在自訂網域 (例如 https://www.contoso.com) 使用 HTTPS 通訊協定，在網際網路上傳送敏感性資料時，便可確保透過 TLS/SSL 加密來安全傳送。 當網頁瀏覽器使用 HTTPS 連線到網站時，會驗證網站安全性憑證，並確認憑證是由合法的憑證授權單位所核發。 此程序可提供安全性，並讓 Web 應用程式免於遭受惡意攻擊。
根據預設，Azure Front Door 支援 Front Door 預設主機名稱上的 HTTPS。 舉例來說，當您建立 Front Door 時 (例如 https://contoso.azurefd.net)，便會針對向 https://contoso.azurefd.net 發出的要求自動啟用 HTTPS。 但當自訂網域「www.contoso.com」上線後，則須另外啟用此前端主機的 HTTPS。
自訂 HTTPS 功能的一些重要特色如下：
無額外成本：取得或更新憑證不需要成本，HTTPS 流量也不會產生額外成本。
容易啟用：從 Azure 入口網站按一下就能佈建。 您也可以使用 REST API 或其他開發工具來啟用此功能。
可以使用完整憑證管理：為您處理所有憑證採購及管理。 憑證會自動佈建並在到期之前更新，消除因為憑證到期而中斷服務的風險。
在本教學課程中，您會了解如何：
- 在您的自訂網域上啟用 HTTPS 通訊協定。
- 使用 AFD 受控憑證
- 使用您自己的憑證，即自訂 TLS/SSL 憑證
- 驗證網域
- 在您的自訂網域上停用 HTTPS 通訊協定
注意
建議您使用 Azure Az PowerShell 模組來與 Azure 互動。 若要開始使用，請參閱 安裝 Azure PowerShell。 若要了解如何移轉至 Az PowerShell 模組，請參閱將 Azure PowerShell 從 AzureRM 移轉至 Az。
必要條件
您必須先建立 Front Door 和至少一個已上架的自訂網域，才能完成本教學課程中的步驟。 如需詳細資訊，請參閱教學課程：將自訂網域新增到您的 Front Door。
TLS/SSL 憑證
若要啟用 HTTPS 通訊協定以在 Front Door (傳統) 自訂網域上安全地傳遞內容，您必須使用 TLS/SSL 憑證。 您可以選擇使用 Azure Front Door 所管理的憑證，或使用您自己的憑證。
選項 1 (預設值)：使用 Front Door 所管理的憑證
使用 Azure Front Door 所管理的憑證時，只要一些設定變更就可以開啟 HTTPS 功能。 Azure Front Door 會完全處理憑證管理工作，例如購買和更新。 啟用此功能之後，程序就會立即啟動。 如果自訂網域已對應到 Front Door 的預設前端主機 ({hostname}.azurefd.net)，則不需要任何進一步的動作。 Front Door 會處理相關步驟並自動完成您的要求。 不過，如果您的自訂網域對應到其他位置，您就必須使用電子郵件來驗證您的網域擁有權。
依照下列步驟啟用自訂網域的 HTTPS︰
在 Azure 入口網站中，瀏覽到您的 Front Door 設定檔。
在前端主機清單中，選取您想要啟用 HTTPS，以包含您自訂網域的自訂網域。
在 [自訂網域 HTTPS] 區段下選取 [啟用]，並選取 [Front Door 受控] 作為憑證來源。
選取 [儲存]。
繼續驗證網域。
注意
- 針對 Azure Front Door 受控憑證，會強制執行 DigiCert 的 64 字元限制。 如果超出該限制，驗證將會失敗。
- 頂點/根網域 (如 contoso.com) 不支援透過 Front Door 受控憑證啟用 HTTPS。 在此案例中，您可使用自己的憑證。 如需其他詳細資料，請繼續進行選項 2。
選項 2：使用您自己的憑證
您可以使用自己的憑證啟用 HTTPS 功能。 此程序會透過與 Azure Key Vault 的整合來進行，而讓您可以安全地儲存您的憑證。 Azure Front Door 使用此安全機制來取得您的憑證，為此您需要執行一些額外步驟。 建立 TLS/SSL 憑證時，您必須使用屬於 Microsoft 信任 CA 清單的允許憑證授權單位 (CA) 來建立完整的憑證鏈結。 如果您使用非允許的 CA，則會拒絕您的要求。 若出現不含完整鏈結的憑證，則不保證與該憑證相關的要求能如預期運作。
準備金鑰保存庫和憑證
在與 Front Door 相同的 Azure 訂用帳戶中，必須有金鑰保存庫帳戶。 建立 Azure Key Vault 帳戶 (若尚無帳戶)。
警告
Azure Front Door 目前僅支援與 Front Door 設定相同訂用帳戶中的 Key Vault 帳戶。 選擇與您 Front Door 不同訂用帳戶下的 Key Vault 將會失敗。
若您的金鑰保存庫已啟用網路存取限制，則須設定金鑰保存庫允許信任的 Microsoft 服務略過防火牆。
必須將金鑰保存庫設定為使用金鑰保存庫存取原則權限模型。
若已有憑證，則可直接上傳至金鑰保存庫。 否則請直接透過 Azure Key Vault，從 Azure Key Vault 所整合的其中一個合作夥伴憑證授權單位 (CA) 建立新憑證。 將您的憑證上傳為憑證物件，而不是祕密。
注意
Front Door 不支援憑證使用橢圓曲線 (EC) 的密碼編譯演算法。 憑證須為具有分葉和中繼憑證的完整憑證鏈結，且根 CA 須為 Microsoft 受信任 CA 清單的一部分。
註冊 Azure Front Door
使用 Azure PowerShell 或 Azure CLI，將 Azure Front Door 的服務主體註冊為在 Microsoft Entra ID 中的應用程式。
注意
- 此動作需要至少具備 Microsoft Entra ID 中的應用程式管理員角色權限。 每個 Microsoft Entra 租用戶只需要執行一次註冊。
- 應用程式識別碼是由 Azure 特別為 Azure Front Door (傳統) 指派。
- Azure Front Door (傳統) 的應用程式識別碼與 Azure Front Door 標準/進階層的不同。
- 除非您定義不同的範圍，否則指派的角色僅適用於選取的訂用帳戶。
Azure PowerShell
如有需要，請在本機電腦的 PowerShell 中安裝 Azure PowerShell。
在 PowerShell 中執行下列命令：
New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
Azure CLI
視需要，在本機電腦上安裝 Azure CLI。
在 Azure CLI 中執行下列命令：
az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037
授與 Azure Front Door 存取您的金鑰保存庫
授與 Azure Front Door 權限，存取 Azure Key Vault 帳戶中的憑證。
在金鑰保存庫帳戶中，選取 [存取原則]。
選取 [建立] 建立新的存取原則。
在祕密權限中選取取得，以允許 Front Door 擷取憑證。
在憑證權限中選取取得，以允許 Front Door 擷取憑證。
在 [選取主體] 中搜尋 ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037，並選取 [Microsoft.Azure.Frontdoor]。 選取 [下一步]。
在 [應用程式] 中，選取 [下一步]。
在檢閱 + 建立中，選取建立。
注意
若您的金鑰保存庫受到網路存取限制所保護，請務必允許信任的 Microsoft 服務存取金鑰保存庫。
Azure Front Door 現在可存取此金鑰保存庫及所含憑證。
選取要部署的 Azure Front Door 憑證
返回入口網站中的 Front Door。
在自訂網域清單中，選取您要啟用 HTTPS 的自訂網域。
自訂網域頁面隨即出現。
在憑證管理類型底下，選取使用我自己的憑證。
Azure Front Door 需要 Key Vault 帳戶的訂用帳戶與 Front Door 的訂用帳戶相同。 選取金鑰保存庫、秘密和秘密版本。
Azure Front Door 會列出下列資訊：
- 您的訂用帳戶識別碼的金鑰保存庫帳戶。
- 所選金鑰保存庫下的秘密。
- 可用的秘密版本。
注意
為了在金鑰保存庫中有憑證新版本可用時，將憑證自動輪替為最新版本，請將祕密版本設為「最新」。 若已選取特定版本，則須手動重新選取新版本，以便憑證輪替。 部署新版憑證/秘密最多需要 72 -96 小時。
警告
這是僅限 Azure 入口網站的警告。 您必須將服務主體設定為具有 Key Vault 的 GET 權限。 若要讓使用者在入口網站下拉式清單中查看憑證，使用者帳戶必須具有 Key Vault 的 LIST 和 GET 權限。 如果使用者沒有這些權限，他們會在入口網站中看到無法存取的錯誤訊息。 無法存取的錯誤訊息不會影響憑證自動輪替或任何 HTTPS 函式。 如果您不想要變更憑證或版本，則不需要針對此錯誤訊息執行任何動作。 如果您想要變更此頁面上的資訊，請參閱提供 Key Vault 的權限，為您的帳戶新增 Key Vault 的 LIST 和 GET 權限。
使用自己的憑證時，無須進行網域驗證。 請繼續進行等待傳播。
驗證網域
若已有使用中的自訂網域使用 CNAME 記錄對應至自訂端點，或您要使用自己的憑證，則請繼續進行自訂網域已對應至您的 Front Door。 若您網域的 CNAME 記錄項目已不存在或包含 afdverify 子網域，請繼續進行自訂網域未對應至您的 Front Door。
自訂網域已經由 CNAME 記錄對應至您的 Front Door
當您為 Front Door 前端主機新增自訂網域時，便已在網域註冊機構的 DNS 表格中建立 CNAME 記錄，以將它對應至 Front Door 預設 .azurefd.net 主機名稱。 若該 CNAME 記錄仍存在，且不包含 afdverify 子網域，DigiCert 憑證授權單位則會使用該記錄來自動驗證自訂網域的所有權。
若使用自己的憑證，則無須進行網域驗證。
您的 CNAME 記錄應該採用下列格式，其中「名稱」是您的自訂網域名稱，而「值」則是您的 Front Door 預設 .azurefd.net 主機名稱：
| 名稱 | 類型 | 值 |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
如需有關 CNAME 記錄的詳細資訊，請參閱建立 CNAME DNS 記錄。
如果您的 CNAME 記錄格式正確，DigiCert 就會自動驗證您的自訂網域名稱，並且為您的網域名稱建立專用憑證。 DigitCert 不會傳送驗證電子郵件給您，因此您不需要核准您的要求。 憑證有效期限為一年，並且會在到期之前自動更新。 請繼續進行等待傳播。
自動驗證通常只需要幾分鐘。 如果您沒有看到您的網域在一小時內進行驗證，請開啟支援票證。
注意
如果您具有 DNS 提供者的憑證授權單位授權 (CAA) 記錄，它必須包括 DigiCert 作為有效的 CA。 CAA 記錄可讓網域擁有者透過其 DNS 提供者，指定哪些 CA 有權為其網域發行憑證。 如果 CA 收到具有 CAA 記錄之網域的憑證訂單，而且該 CA 未列出為授權簽發者，則禁止該 CA 將憑證發行給該網域或子網域。 如需管理 CAA 記錄的相關資訊，請參閱管理 CAA 記錄。 有關 CAA 記錄工具，請參閱 CAA 記錄協助程式。
自訂網域未對應至您的 Front Door
如果您端點的 CNAME 記錄項目已不存在或包含 afdverify 子網域，請遵循此步驟中的其餘指示進行操作。
在您的自訂網域上啟用 HTTPS 之後，DigiCert CA 會根據網域的 WHOIS 註冊資訊連絡其註冊人，以驗證網域的所有權。 連絡方式為透過電子郵件地址 (預設) 或列示在 WHOIS 註冊資訊中的電話號碼。 必須先完成網域驗證才能在您的自訂網域上啟用 HTTPS。 您有六個工作天可以核准網域。 未於六個工作天內核准的要求將會自動取消。 DigiCert 網域驗證可在子網域層級運作。 您必須個別證明各子網域的所有權。
DigiCert 也會將驗證電子郵件傳送至其他電子郵件地址。 如果 WHOIS 註冊者資訊為私用，請確認您可以直接從下列其中一個地址核准：
admin@<your-domain-name.com> administrator@<your-domain-name.com> webmaster@<your-domain-name.com> hostmaster@<your-domain-name.com> postmaster@<your-domain-name.com>
您應該會在幾分鐘之內收到請求您核准要求的電子郵件，如以下範例所示。 若您使用垃圾郵件篩選器，請將 no-reply@digitalcertvalidation.com 新增至允許清單。 在某些情況下，DigiCert 可能無法從 WHOIS 註冊者資訊擷取網域連絡人並傳送電子郵件給您。 如果您未在 24 小時內收到驗證電子郵件，請連絡 Microsoft 支援服務。
選取核准連結時，系統會將您導向線上核准表單。 遵循表單上的指示；您有兩個驗證選項：
您可以核准未來所有經相同帳戶針對同一個根網域 (如 contoso.com) 的所有訂購。 若您計劃新增相同根網域的其他自訂網域，建議使用這種方法。
您可以只核准這次要求使用的特定主機名稱。 後續的要求需要另外核准。
核准之後，DigiCert 會針對您的自訂網域名稱完成憑證建立。 憑證有效期限為一年，並且會在到期之前自動更新。
等待傳播
自訂網域 HTTPS 功能要在網域名稱通過驗證之後 6-8 小時才會啟用。 當流程完成時，Azure 入口網站中的自訂 HTTPS 狀態會設定為 [已啟用]，而且 [自訂網域] 對話方塊中的四個作業步驟會標示為完成。 您的自訂網域現在已準備好使用 HTTPS。
作業進度
下表列出停用 HTTPS 時的作業進度。 啟用 HTTPS 之後，四個作業步驟會出現在 [自訂網域] 對話方塊中。 隨著每個步驟變成作用中狀態，其他子步驟詳細資料會在步驟進行時顯示於下方。 這裡的所有子步驟並非都會發生。 各個步驟完成時，旁邊都會出現一個綠色的核取記號。
| 作業步驟 | 作業子步驟詳細資料 |
|---|---|
| 1.提交要求 | 提交要求 |
| 正在提交您的 HTTPS 要求。 | |
| 已成功提交您的 HTTPS 要求。 | |
| 2.網域驗證 | 若網域對應至 Front Door 預設的 .azurefd.net 前端主機 CNAME，則會自動驗證。 否則，系統會將驗證要求傳送到您網域註冊記錄 (WHOIS 註冊者) 中所列的電子郵件。 請儘速驗證網域。 |
| 已成功驗證您的網域擁有權。 | |
| 網域擁有權驗證要求已過期 (客戶可能未在 6 天內回應)。 您網域上的 HTTPS 將不會啟用。 * | |
| 客戶拒絕網域所有權驗證要求。 您網域上的 HTTPS 將不會啟用。 * | |
| 3.憑證佈建 | 憑證授權單位正在發行在網域上啟用 HTTPS 所需的憑證。 |
| 憑證已發行，目前正在部署至您的 Front Door。 此流程可能需要幾分鐘到一小時完成。 | |
| 已成功將憑證部署至您的 Front Door。 | |
| 4.[完成] | 已成功在您的網域上啟用 HTTPS。 |
* 除非發生錯誤，否則不會出現這則訊息。
如果錯誤發生於提交要求之前，則會顯示下列錯誤訊息：
We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.
常見問題集
憑證提供者是誰？使用的是哪一種憑證？
由 Digicert 提供的專用/單一憑證會用於您的自訂網域。
您使用 IP 型或 SNI TLS/SSL？
Azure Front Door 使用 SNI TLS/SSL。
如果沒有收到 DigiCert 的驗證電子郵件該怎麼辦？
若自訂網域的 CNAME 項目直接指向端點主機名稱 (且您未使用 afdverify 子網域名稱)，則不會收到網域驗證電子郵件。 驗證會自動進行。 否則，如果您沒有 CNAME 項目且未在 24 小時內收到電子郵件，請連絡 Microsoft 支援服務。
SAN 憑證的安全性是否比專用憑證來得低？
SAN 憑證遵循和專用憑證相同的加密與安全性標準。 所有發行的 TLS/SSL 憑證都使用 SHA-256 來加強伺服器安全性。
是否需要我的 DNS 提供者的憑證授權單位授權記錄？
否，目前不需要憑證授權單位授權記錄。 不過，如果您的確有一個授權記錄，它必須包含 DigiCert 作為有效的 CA。
清除資源
在先前步驟中，您已在自訂網域上啟用 HTTPS 通訊協定。 若您不要再使用自訂網域搭配 HTTPS，則可執行下列步驟來停用 HTTPS：
停用 HTTPS 功能
在 Azure 入口網站中，瀏覽至您的 [Azure Front Door] 設定。
在前端主機清單中，選取要停用 HTTPS 的自訂網域。
選取 [停用] 以停用 HTTPS，然後選取 [儲存]。
等待傳播
自訂網域 HTTPS 功能停用之後，可能需要 6-8 小時才會生效。 當流程完成時，Azure 入口網站中的自訂 HTTPS 狀態會設定為 [已停用]，且 [自訂網域] 對話方塊中的三個作業步驟會標示為完成。 您的自訂網域無法再使用 HTTPS。
作業進度
下表指出停用 HTTPS 時的作業進度。 停用 HTTPS 之後，三個作業步驟會出現在 [自訂網域] 對話方塊中。 隨著每個步驟變成作用中狀態，其他詳細資料會顯示在步驟下方。 各個步驟完成時，旁邊都會出現一個綠色的核取記號。
| 作業進度 | 作業詳細資料 |
|---|---|
| 1.提交要求 | 正在提交您的要求 |
| 2.憑證取消佈建 | 刪除憑證 |
| 3.[完成] | 已憑證刪除 |
下一步
若要了解如何為您的 Front Door 設定地區篩選原則，請繼續進行下一個教學課程。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應