Let’s Encrypt 如何通過不安全的 http 驗證身份？
我剛開始使用 Let’s Encrypt。http-01-challenge 很簡單：
- 讓網路伺服器響應http://example.com
- 向 Let’s Encrypt 詢問質詢文件
- 在http://example.com/.well-known/acme-challenge下提供文件
- 接收 example.com 的 TLS 證書
奇蹟般有效。但是他們如何使用不安全的 http 連接確保我真的是 example.com 的所有者？
我的數據中心（或我的 ISP）中的某些管理員不能請求證書並攔截 http 請求，讓我們加密發送以檢查伺服器的身份嗎？
事實上，對於 HTTP-01 挑戰，對於中間人攻擊沒有萬無一失的保護措施。
可以攔截 Let’s Encrypt 驗證節點和您的伺服器之間的流量的人可以通過挑戰並獲得頒發的證書。如果他們能夠實施 BGP 詭計，他們可能甚至不一定處於正常意義上的中間。
這適用於 HTTP-01 質詢，對於未簽名域也適用於 DNS-01 質詢。
值得注意的是，這個問題並不是 Lets Encrypt 獨有的，傳統 CA 對 DV 證書的驗證普遍存在同樣的問題；它們通常提供 HTTP、DNS 和電子郵件驗證選項，所有這些都容易受到 MITM 攻擊。
Let’s Encrypt為緩解該問題所做的工作是從不同數據中心的多個測試節點執行每個驗證，要求所有測試結果一致才能頒發證書。（我懷疑這使得他們比大多數傳統 CA 更不容易受到這種類型的濫用。）
這至少減少了可能處於“中間”的人的範圍，因為“中間”的大部分將與所看到的不同來自不同的測試節點。
這都是關於 Let’s Encrypt（以及一般的 CA）自動域驗證的預設行為，但是域所有者已經獲得了一些額外的控制權，要求公共 CA 必須檢查
CAA記錄。為了實際控制，域所有者可以採取以下步驟：
- DNSSEC-簽署區域以確保
CAA數據不被篡改（在 DNS-01 的情況下也保護挑戰本身） 2. 添加一條或多
CAA條記錄以限制證書的頒發（特別
CAA是那些不僅命名允許頒發的 CA，而且還包括允許該 CA 的帳戶的記錄）記錄看起來像
CAA這樣：example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"這個問題大大減少了，因為冒名頂替者不能一開始就輕易發起挑戰。
特別注意數據中的
accounturi參數CAA，這是使策略特定於具有指定 CA 的域所有者帳戶的原因。僅指定 CA 而不是帳戶的
CAA記錄雖然有效，但幫助有限，因為這樣的策略仍然允許該 CA 的任何其他客戶請求頒發證書。