上次更新：2023 年 8 月 16 日 | 檢視所有文件

CAA 是一種 DNS 記錄類型，允許網站擁有者指定哪些憑證授權機構 (CA) 可以核發包含其網域名稱的憑證。它於 2013 年首次標準化，而我們今天使用的版本則由 RFC 8659 和 RFC 8657 在 2019 年標準化。預設情況下，每個公開 CA 都被允許核發任何公開 DNS 中網域名稱的憑證，前提是他們驗證了該網域名稱的控制權。這表示如果任何一個公開 CA 的驗證過程中存在錯誤，則每個網域名稱都可能受到影響。CAA 提供了一種讓網域持有者降低風險的方法。

使用 CAA

如果您不關心 CAA，通常不需要執行任何動作（但請參閱下方的 CAA 錯誤）。如果您想使用 CAA 來限制哪些憑證授權機構可以核發您的網域憑證，您需要使用支援設定 CAA 記錄的 DNS 提供商。請查看 SSLMate 的 CAA 頁面，以取得這類提供商的清單。如果您的提供商已列出，您可以使用 SSLMate 的 CAA 記錄產生器，以產生一組列出您想要允許的 CA 的 CAA 記錄。

記錄的放置位置

一般而言，您需要在您註冊的網域上設定 CAA 記錄（例如「example.org」或「mysite.co.uk」）。這樣，它們會同時套用至該網域和您在其下建立的任何子網域，例如「community.example.org」。

請注意，CA 一律會遵守與其核發憑證的網域名稱最接近的 CAA 記錄。因此，如果您要求「www.community.example.org」的憑證，CA 將會檢查「www.community.example.org」，然後檢查「community.example.org」，最後檢查「example.org」，並在找到的第一個 CAA 記錄處停止。

這表示您可以覆寫子網域的 CAA。例如，假設您自行託管「example.org」，但在雲端提供商上擁有「api.example.org」。您可以在「example.org」上使用 CAA 記錄，以指出只有 Let's Encrypt 可以核發該網域及其所有子網域的憑證，也可以在「api.example.org」上使用 CAA 記錄來覆寫該記錄，並允許雲端提供商核發該子網域的憑證。

另請注意，CAA 檢查會遵循 CNAME 重新導向，就像所有其他 DNS 要求一樣。如果「community.example.org」是重新導向至「example.forum.com」的 CNAME，CA 將會遵守在「example.forum.com」上設定的任何 CAA 記錄。具有 CNAME 記錄的網域名稱不得有任何其他記錄，因此原始名稱上的 CAA 記錄與重新導向目標上的 CAA 記錄之間不會發生衝突。

記錄中要放置什麼

所有 CAA 記錄都遵循相同的基本格式

CAA <flags> <tag> <value>

旗標只是一個整數，且幾乎都應該只是整數 0，表示沒有設定任何旗標。如果您願意，您可以將旗標設定為整數 128，表示已設定「重要位元」，且如果 CA 無法辨識標籤欄位的內容，就應該立即停止並停止核發憑證。

標籤是一個字串，表示這是哪種類型的 CAA 記錄：在大多數情況下是 issue 或 issuewild。下方將詳細說明。

最後，值是一個字串，其中最多包含一個 CA 識別碼（例如「letsencrypt.org」）和一些選用的分號分隔參數，如下所述。

`issue` 和 `issuewild` 屬性

具有 issue 標籤的記錄只會控制 CA 是否可以核發此網域及其子網域的憑證。一般來說，這是您唯一需要的記錄，因為在沒有任何其他記錄的情況下，它會控制一般憑證（例如「example.org」）和萬用字元憑證（例如「*.example.org」）的核發。您可以將 CA 的識別網域名稱放置在 CAA 記錄的值部分，以控制哪個 CA 可以核發此網域的憑證。

具有 issuewild 標籤的記錄會控制 CA 是否可以核發萬用字元憑證（例如「*.example.org」）。如果您想要針對萬用字元和非萬用字元核發設定不同的權限，則只需要使用 issuewild 記錄。

請注意，您可以擁有具有相同屬性類型的多個記錄，它們是累加的：如果任何一個記錄允許 CA 核發憑證，則會允許該 CA 核發憑證。

Let's Encrypt 的 CAA 識別網域名稱是 letsencrypt.org。這在我們的 CP/CPS 的第 4.2.1 節中有正式記錄。

`validationmethods` 參數

此參數可以放置在 CA 的識別網域名稱之後，以控制 CA 可以使用哪些驗證方法來確認網域的控制權。這可以用來將驗證限制為您更信任的方法。例如，如果您想要將 CA 限制為僅使用 TLS-ALPN-01 方法，您可以將 ;validationmethods=tls-alpn-01 附加至您的 CAA 記錄值。

Let's Encrypt 可辨識下列驗證方法字串

http-01
dns-01
tls-alpn-01

`accounturi` 參數

此參數可以放置在 CA 的識別網域名稱之後，以控制哪些 ACME 帳戶可以要求核發該網域的憑證。這可以用來確保暫時劫持您網域，但無法存取您 ACME 帳戶金鑰的使用者，無法核發惡意憑證。

Let's Encrypt 的帳戶 URI 看起來像 https://acme-v02.api.letsencrypt.org/acme/acct/1234567890，其中結尾的數字是您的帳戶 ID。

範例

允許 Let's Encrypt 核發「example.org」憑證的簡單 CAA 記錄可能如下所示

example.org         CAA 0 issue "letsencrypt.org"

更複雜的 CAA 記錄集可能如下所示

example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"

在此範例中，MyCA 可以核發「example.org」的憑證，但僅限使用 DNS-01 驗證方法。它也可以使用任何驗證方法來核發萬用字元憑證。最後，OtherCA 也可以核發憑證，但前提是要求來自帳戶號碼 123456，而且只有在 OtherCA 可辨識且知道如何正確處理 accounturi 限制的情況下。

CAA 錯誤

由於 Let's Encrypt 會在我們核發每個憑證之前檢查 CAA 記錄，因此有時即使針對未設定任何 CAA 記錄的網域，我們也會收到錯誤。當我們收到錯誤時，我們無法判斷是否允許核發受影響網域的憑證，因為可能存在禁止核發的 CAA 記錄，但由於錯誤而無法看到這些記錄。

如果您收到與 CAA 相關的錯誤，請對我們的暫存環境嘗試幾次，以查看這些錯誤是暫時性還是永久性。如果它們是永久性的，您需要向您的 DNS 提供商提交支援問題，或更換提供商。如果您不確定您的 DNS 提供商是誰，請諮詢您的託管提供商。

有些不熟悉 CAA 的 DNS 提供商最初會回覆問題報告，內容為「我們不支援 CAA 記錄」。您的 DNS 提供商不需要特別支援 CAA 記錄；它只需要針對未知的查詢類型（包括 CAA）回覆 NOERROR 回應。針對無法辨識的 qtype 回傳其他運算碼，包括 NOTIMP，是違反 RFC 1035 的行為，而且需要修正。

SERVFAIL

人們遇到最常見的錯誤之一是 SERVFAIL。這通常表示 DNSSEC 驗證失敗。如果您收到 SERVFAIL 錯誤，您的第一步應該是使用像 dnsviz.net 這樣的 DNSSEC 偵錯工具。如果該工具無效，則可能是您的名稱伺服器只有在回應為空時才會產生不正確的簽名。而 CAA 回應通常都是空的。例如，PowerDNS 在 4.0.3 及更早的版本中就存在這個錯誤。

如果您未啟用 DNSSEC 並收到 SERVFAIL，第二個最可能的原因是您的授權名稱伺服器回傳了 NOTIMP，如上所述，這是違反 RFC 1035 的行為；它應該改為回傳具有空白回應的 NOERROR。如果發生這種情況，請向您的 DNS 提供商提出錯誤或支援票證。

最後，SERVFAIL 可能是由於您授權名稱伺服器的停機所導致。請檢查您的名稱伺服器的 NS 記錄，並確保每個伺服器都可用。

逾時

有時 CAA 查詢會逾時。也就是說，授權名稱伺服器完全不會回覆任何答案，即使在多次重試之後也是如此。最常見的情況是當您的名稱伺服器在其前面有設定錯誤的防火牆時，該防火牆會捨棄具有未知 qtype 的 DNS 查詢。請向您的 DNS 提供商提交支援票證，並詢問他們是否已設定這類防火牆。

憑證授權機構授權 (CAA)