為什麼 ACM 所核發憑證的 CNAME 記錄無法解析，且 DNS 驗證狀態仍為「待驗證」？

簡短說明

DNS 驗證的憑證請求可能會因以下原因而持續處於「待驗證」狀態：

• 您沒有將 CNAME 記錄新增到正確的 DNS 組態中。
• CNAME 記錄包含額外的字元或缺少字元。
• 您已將 CNAME 記錄新增到正確的 DNS 組態中，但 DNS 提供者自動在 DNS 記錄末尾新增了裸網域。
• 相同網域名稱的 CNAME 記錄和 TXT 記錄同時存在。
• 網域已啟用 DNSSEC，但組態不正確。
  注意： ACM 會定期檢查 DNS 記錄。您無法自行檢查 DNS 記錄。

解決方法

注意： 在您的機器終端中執行 Linux 和 macOS 指令。或者，在 PowerShell 或 cmd 中執行 Windows 指令。

您沒有將 CNAME 記錄新增到正確的 DNS 組態中

注意： 在下列命令中，請將 example-cname.example.com 替換成您的 ACM CNAME 記錄。

依您的作業系統 (OS) 執行以下命令，檢查是否已將 CNAME 記錄新增至正確的 DNS 組態中：

Linux 和 macOS：

dig +short _example-cname.example.com

Windows：

nslookup -type=cname _example-cname.example.com

注意： 如果您已將 CNAME 記錄新增到正確的 DNS 組態中且該記錄已傳播完成，則命令輸出結果會包含 CNAME 記錄的值。某些 DNS 提供者可能需要 24 到 48 小時來傳播 DNS 記錄。

若命令未傳回任何輸出，請將 CNAME 記錄新增至正確的 DNS 組態中。

依您的作業系統執行以下命令，確認您必須新增 CNAME 記錄的 DNS 組態：

Linux 和 macOS：

dig NS example.com

Windows：

nslookup -type=ns example.com

注意： 輸出結果會提供正確 DNS 組態中 NS 記錄的名稱伺服器。

請確認您新增 CNAME 記錄的 DNS 組態中，包含帶有這些名稱伺服器的 NS 記錄。

如需了解如何將 CNAME 記錄新增至 Amazon Route 53 託管區域，請參閱使用 Amazon Route 53 主控台建立記錄。

注意： 當 CNAME 記錄位於 Route 53 私有託管區域時，您無法驗證網域所有權。CNAME 記錄必須位於公有託管區域中。

CNAME 記錄是否包含額外字元或缺少字元

如果 CNAME 記錄包含額外字元，請將其移除。如果名稱或值中缺少字元，請將其補上。

DNS 提供者將裸網域附加到 CNAME 記錄名稱

有些 DNS 提供者可能會自動將裸網域附加到所有 DNS 記錄的名稱欄位結尾。傳播的 CNAME 記錄類似於以下項目：

_example-cname.example.com.example.com

因為 CNAME 記錄名稱與 ACM 提供的名稱不符，因此驗證失敗。ACM 憑證會保持在待驗證狀態，直到在請求後 72 小時失敗後為止。

針對您的作業系統執行下列命令，以判斷 DNS 提供者是否自動將裸網域附加到 CNAME 記錄中：

Linux 和 macOS：

dig +short _example-cname.example.com.example.com

Windows：

nslookup -type=cname _example-cname.example.com.example.com

如果輸出傳回 CNAME 記錄的值，則您的 DNS 提供者已新增裸網域。

要解決此問題，請編輯您的 CNAME 記錄，將名稱欄位輸入內容中的裸網域移除。DNS 提供者新增裸網域後，最終就只會保留一個裸網域。

相同網域名稱的 CNAME 記錄和 TXT 記錄同時存在

若要檢查是否存在相同網域的 CNAME 記錄和 TXT 記錄，請執行下列指令：

Linux 和 macOS：

dig +short CNAME cname_record_name
dig TXT cname_record_name

Windows：

nslookup -type=CNAME cname_record_name
nslookup -type=TXT cname_record_name

注意： 在上述命令中，請將 cname_record_name 替換成您的 CNAME 記錄名稱。

比較輸出結果中的 CNAME 記錄與 TXT 記錄類型。如果記錄類型完全相同，代表格式錯誤的記錄導致憑證停留在待驗證狀態。若要解決此問題，請刪除 TXT 記錄。如需更多資訊，請參閱 Troubleshoot DNS validation problems (排解 DNS 驗證問題)。

已為網域設定 DNSSEC，但驗證失敗

如果您的網域使用 DNSSEC 但設定不正確，ACM 就無法驗證您的憑證。私有 CA 核發的憑證必須隸屬於具備有效 DNSSEC 信任鏈的網域。啟用 DNSSEC 時，ACM 會在網域控制驗證 (DCV) 和憑證頒發機構授權 (CAA) 記錄查詢期間，將 DNSSEC 簽追溯驗證回 IANA 根信任錨。若該信任鏈中的任何連結中斷或設定錯誤，DNSSEC 驗證便會失敗，且 DNS 回應會被視為不可靠。這將導致無法核發或續訂憑證。

注意： 未設定 DNSSEC 的網域不受影響。當 ACM 查詢未設定 DNSSEC 的網域時，ACM 會將回應歸類為「不安全」，且核發流程會正常進行。

針對您的作業系統執行下列命令，確認問題是否由 DNSSEC 引起：

Linux 和 macOS：

  dig @8.8.8.8 _example-cname.example.com CNAME

Windows：

  nslookup -type=cname _example-cname.example.com 8.8.8.8

注意： 請將 _example-cname.example.com 替換成您的 ACM CNAME 記錄。

如果回應顯示的狀態為 SERVFAIL，而非 NOERROR 或「Server failed」(伺服器失敗)，則代表 DNSSEC 驗證可能會失敗。

若要在 Linux 與 macOS 上進行確認，請在關閉 DNSSEC 檢查的情況下執行下列查詢：

  dig @8.8.8.8 _example-cname.example.com CNAME +cd

如果附加 +cd 的查詢傳回了正確的 CNAME 值，但未附加該參數的查詢卻傳回 SERVFAIL，則代表 DNSSEC 設定錯誤阻礙了 ACM 驗證。

請執行下列命令，以檢查您的網域是否已啟用 DNSSEC：

  dig DS example.com +short

注意： 如果輸出結果傳回了 DS 記錄，則可確認您的網域已啟用 DNSSEC。

請執行下列命令，以檢查您的區域中是否存在相符的 DNSKEY 記錄：

  dig DNSKEY example.com +short

如果父區域存在 DS 記錄，但您的區域中不存在相符的 DNSKEY 記錄，則代表 DNSSEC 信任鏈已中斷。

注意： dig DS 與 DNSKEY 命令僅適用於 Linux 與 macOS。若為 Windows，請使用線上 DNSSEC 診斷工具來檢查信任鏈。

如果您的網域不需要 DNSSEC，請執行下列動作：

• 移除網域註冊商的 DS 記錄。如需指示，請參閱 Deleting public keys for a domain (刪除網域的公用金鑰)。
• 等待 DNS 傳播，這最多可能需要 48 小時。
• 確認 dig DS example.com +short 不再傳回 DS 記錄。
• 重試憑證核發。如果現有憑證已逾時，請將其刪除並重新申請新的憑證。

如果您的網域需要 DNSSEC，請執行下列動作：

比較父區域的 DS 記錄與您區域中的 DNSKEY 記錄，然後找出信任鏈中具體的中斷點

修正您的 DNS 提供者或網域註冊商的錯誤設定。若要修正 DNSSEC 錯誤設定，請執行下列動作：

• 更新不相符的 DS 記錄，使其與您區域中目前的 DNSKEY 相符。

• 啟用您在 Route 53 中用於 DNSSEC 簽章的 AWS Key Management Service (KMS) key。

• 在父區域中，為已啟用 DNSSEC 簽章的子網域新增 DS 記錄。

• 請執行下列命令，確認輸出結果是否傳回 NOERROR 狀態以及預期值：

  @8.8.8.8 _example-cname.example.com

  注意： 在正確設定 DNSSEC 之後，ACM 會在下一次定期檢查時自動重試網域驗證。

如需更多資訊，請參閱 Configuring DNSSEC for a domain (為網域設定 DNSSEC)。

相關資訊

排解受管憑證續訂問題

為什麼我對網域名稱使用 ACM 受管續訂程序後，ACM 憑證的續訂狀態仍為「待驗證」？

設定 DNS 驗證