DNS CAA: Giới hạn CA được phép cấp chứng thư TLS

Một tên miền không có bản ghi CAA thường không giới hạn CA công khai nào được phép cấp chứng thư cho nó. Bản ghi DNS CAA (Certification Authority Authorization) cho chủ tên miền công bố danh sách tổ chức chứng thực được ủy quyền, nhờ đó thu hẹp một lớp rủi ro cấp nhầm chứng thư.

CAA ngắn gọn nhưng dễ cấu hình sai: issuewild không đơn giản là bản sao của issue, bản ghi ở tên con có thể thay thế chính sách kế thừa từ tên cha, và một mã CA nhập theo phỏng đoán có thể khiến gia hạn tự động thất bại. Bài viết này xây cấu hình từ mô hình hoạt động, rồi mới đi đến lệnh kiểm tra và rollout.

1. CAA kiểm soát điều gì?

CAA là chỉ dẫn dành cho CA tại thời điểm phát hành chứng thư. Theo RFC 8659, CA tuân thủ phải tìm RRset CAA liên quan và không được cấp nếu yêu cầu không phù hợp với chính sách đó, trừ ngoại lệ được mô tả trong CP/CPS của CA.

Trình duyệt không đọc CAA trong mỗi lần người dùng mở website. CAA cũng không thu hồi chứng thư đã cấp, không thay thế xác minh quyền kiểm soát tên miền, không bảo vệ khóa riêng và không ngăn một CA đã được cho phép cấp nhầm. Nó là một lớp kiểm soát trước khi cấp phát, nên vẫn cần quản lý tài khoản CA, ACME credential, Certificate Transparency và giám sát DNS.

2. Cú pháp một bản ghi CAA

example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"

Mỗi record có ba thành phần dữ liệu:

• Flags: thường là 0. Giá trị 128 bật issuer-critical flag cho một tag; nếu CA không hiểu tag critical đó, CA phải từ chối cấp.
• Tag: thuộc tính như issue, issuewild hoặc iodef.
• Value: issuer-domain-name hoặc URL báo cáo, tùy tag. Đây không nhất thiết là hostname API hay tên thương mại của CA.

Giao diện DNS có thể tách flags, tag và value thành ba ô; một số nơi nhận toàn bộ chuỗi. Không thêm dấu ngoặc kép vào value nếu giao diện tự xử lý quoting. Luôn xem lại bằng truy vấn DNS công khai thay vì chỉ tin màn hình quản trị.

3. Ba tag cần biết

Ví dụ cho phép Let's Encrypt cấp cả chứng thư thường và wildcard:

example.com.  CAA 0 issue     "letsencrypt.org"
example.com.  CAA 0 issuewild "letsencrypt.org"
example.com.  CAA 0 iodef     "mailto:security@example.com"

Tài liệu CAA của Let's Encrypt xác nhận issuer-domain-name của dịch vụ là letsencrypt.org. Với CA khác, hãy lấy đúng giá trị từ tài liệu chính thức hiện hành; không suy ra từ tên công ty hay issuer hiển thị trong một chứng thư cũ.

4. Không có CAA khác với CAA rỗng

Nếu không tìm thấy RRset CAA liên quan, CAA không đặt giới hạn cấp phát. Muốn yêu cầu không CA nào được cấp, RFC 8659 định nghĩa giá trị issue không có issuer-domain-name:

nocerts.example.com.  CAA 0 issue ";"

Đây là chính sách “cấm cấp”, không phải placeholder. Không dùng nó trên tên miền đang cần gia hạn trừ khi có record cho phép phù hợp trong cùng RRset. Các ủy quyền là cộng dồn: nếu cùng RRset có cả issue ";" và issue "ca.example", record CA không rỗng vẫn cấp quyền cho CA đó.

Một RRset chỉ có iodef hoặc tag không được nhận diện không tự động cấm cấp. Muốn giới hạn phải có issue hoặc issuewild đúng ngữ nghĩa.

5. Cách kế thừa từ tên cha hoạt động

CA bắt đầu ở FQDN cần cấp rồi đi dần lên cây DNS cho đến khi gặp RRset CAA đầu tiên. Ví dụ, nếu api.dev.example.com không có CAA nhưng example.com có, chính sách ở apex được kế thừa. Nếu dev.example.com có bất kỳ RRset CAA nào, đó là tập liên quan và quá trình dừng tại đây.

example.com.      CAA 0 issue "ca-a.example"
dev.example.com. CAA 0 issue "ca-b.example"

Trong ví dụ này, api.dev.example.com dùng chính sách của dev.example.com, không cộng thêm CA ở example.com. Điều này vừa cho phép ủy quyền theo nhánh, vừa tạo bẫy khi ai đó thêm một record CAA lẻ ở subdomain mà quên các CA hợp lệ khác.

RFC 8659 yêu cầu lookup theo cơ chế DNS, bao gồm xử lý alias, nhưng thuật toán đi lên cây chỉ áp dụng cho FQDN đang được xét. Với CNAME/CDN/SaaS, hãy kiểm tra cả tên khách hàng, chuỗi alias thực tế và tài liệu nhà cung cấp; đừng giả định policy tại đích CNAME thay thế được policy của tên ban đầu.

6. Wildcard: chỗ dễ nhầm nhất

Nếu RRset không có issuewild, các record issue cũng quyết định CA nào được cấp wildcard. Nhưng khi có ít nhất một issuewild, toàn bộ issue bị bỏ qua riêng cho yêu cầu wildcard.

example.com. CAA 0 issue     "ca-a.example"
example.com. CAA 0 issuewild "ca-b.example"

Kết quả: CA A được cấp chứng thư cho example.com và tên thường; CA B được cấp cho *.example.com. Nếu muốn cấm wildcard nhưng vẫn cho CA A cấp chứng thư thường:

example.com. CAA 0 issue     "ca-a.example"
example.com. CAA 0 issuewild ";"

Wildcard *.example.com chỉ bao phủ một nhãn như www.example.com, không tự bao phủ a.b.example.com. CAA và phạm vi hostname trên chứng thư là hai vấn đề khác nhau.

7. Cho phép nhiều CA mà không tạo điểm mù

Mỗi CA được phép cần một record riêng. Không ghép nhiều issuer vào một chuỗi phân cách bằng dấu phẩy:

example.com. CAA 0 issue "ca-primary.example"
example.com. CAA 0 issue "ca-backup.example"

Chỉ thêm CA dự phòng nếu quy trình thật sự có thể dùng nó. Một danh sách quá rộng làm giảm giá trị kiểm soát; danh sách quá hẹp làm hỏng failover hoặc chứng thư do CDN, nền tảng hosting, email gateway và dịch vụ SaaS cấp thay. Hãy lập inventory theo hostname và chủ sở hữu trước khi chỉnh policy.

8. Tham số nâng cao: chỉ dùng khi CA hỗ trợ

RFC 8657 định nghĩa accounturi để ràng buộc quyền cấp với một tài khoản CA và validationmethods để giới hạn phương thức xác minh. Ví dụ khái niệm:

example.com. CAA 0 issue "ca.example; accounturi=https://ca.example/acct/123"
example.com. CAA 0 issue "ca.example; validationmethods=dns-01"

Các tham số nằm trong namespace do CA xử lý. Chúng chỉ có tác dụng khi CA được nêu hỗ trợ đúng tham số và định dạng. Sao chép URI mẫu hoặc tham số từ CA khác có thể biến authorization thành không thỏa mãn và chặn cấp phát.

9. Kiểm tra record từ nhiều góc nhìn

Trên Linux/macOS hoặc máy có BIND tools:

dig CAA example.com +short
dig CAA www.example.com +short
dig CAA sub.example.com @1.1.1.1 +short
dig CAA sub.example.com @8.8.8.8 +short

Trên Windows PowerShell:

Resolve-DnsName example.com -Type CAA
Resolve-DnsName sub.example.com -Type CAA -Server 1.1.1.1

Nếu công cụ hoặc resolver cũ không hỗ trợ type CAA, cập nhật công cụ hay dùng resolver khác; đừng kết luận record không tồn tại chỉ từ một lỗi parser. Kiểm tra authoritative nameserver, ít nhất hai recursive resolver và từng SAN trong yêu cầu chứng thư. Với DNSSEC, kiểm tra thêm trạng thái validation thay vì chỉ thấy record.

10. Quy trình triển khai không làm hỏng gia hạn

1. Inventory: liệt kê chứng thư đang dùng, toàn bộ SAN/wildcard, CA phát hành, CDN/SaaS và cơ chế ACME.
2. Xác nhận identifier: đọc tài liệu chính thức của từng CA hoặc nhà cung cấp managed certificate.
3. Thiết kế RRset: quyết định CA thường, CA wildcard, địa chỉ báo cáo và policy theo subdomain.
4. Giảm TTL trước: thực hiện đủ sớm để cache cũ hết hạn; TTL thấp không xóa cache đã tồn tại.
5. Thêm quyền trước: triển khai record cho mọi CA đang hoạt động, chưa vội loại bỏ.
6. Quan sát propagation: truy vấn authoritative và recursive resolvers tại nhiều vị trí.
7. Thử staging hoặc dry-run: dùng chức năng test của ACME client/nhà cung cấp nếu có, tránh chạm rate limit production.
8. Gia hạn thử có kiểm soát: xác nhận CA đọc đúng policy và chứng thư mới được triển khai.
9. Thu hẹp: chỉ xóa CA cũ sau khi chắc chắn không còn dependency.

11. Chẩn đoán khi CA báo lỗi CAA

• Truy vấn đúng từng hostname trong SAN, không chỉ apex domain.
• Tìm RRset gần nhất trên cây DNS; một record ở subdomain có thể che policy tên cha.
• Kiểm tra issuewild khi yêu cầu chứa wildcard.
• Xác minh spelling, dấu chấm phẩy và issuer-domain-name theo tài liệu CA.
• Theo chuỗi CNAME và kiểm tra SERVFAIL, timeout, DNSSEC validation failure.
• Chờ TTL hợp lý; resolver của CA có thể còn cache câu trả lời trước đó.
• Kiểm tra nền tảng có dùng CA trung gian/dự phòng khác với CA bạn tưởng hay không.
• Không xóa toàn bộ CAA như phản xạ đầu tiên; lưu lại câu trả lời DNS để tìm nguyên nhân.

12. Các hiểu lầm phổ biến

• “CAA làm chứng thư hiện tại vô hiệu”: không; nó tác động đến quyết định cấp mới/gia hạn.
• “Có iodef là đã khóa CA”: không; iodef chỉ khai báo kênh báo cáo.
• “Một issue cho phép đúng một CA”: một RRset có thể có nhiều record issue, và quyền là cộng dồn.
• “issuewild bắt buộc để cấp wildcard”: không; nếu thiếu nó, issue áp dụng cho wildcard.
• “CAA thay thế DNSSEC”: không; DNSSEC giúp xác thực dữ liệu DNS, còn CAA biểu đạt chính sách cấp phát.
• “CAA ngăn mọi mis-issuance”: không; CA được cho phép vẫn có thể cấp nhầm, và hiệu quả phụ thuộc CA tuân thủ.

Checklist production

• Đã kiểm kê mọi chứng thư, SAN, wildcard và dịch vụ cấp thay.
• Mỗi issuer-domain-name lấy từ tài liệu chính thức hiện hành.
• Hiểu rõ policy kế thừa và mọi RRset ở subdomain.
• issuewild phản ánh đúng chủ đích cho wildcard.
• Không dùng flags 128 với tag chưa được các CA cần thiết hỗ trợ.
• Record được nhìn thấy từ authoritative và nhiều recursive resolver.
• Đã thử gia hạn sau thay đổi và theo dõi lỗi ACME.
• Có cảnh báo Certificate Transparency ngoài danh sách dự kiến.
• Thay đổi DNS có owner, review và phương án rollback.

Kết luận

DNS CAA là một kiểm soát nhỏ nhưng hữu ích khi được xây từ inventory thật. Bắt đầu với issue cho các CA đang dùng, tách issuewild khi chính sách wildcard khác biệt, rồi kiểm tra kế thừa trên từng hostname. CAA không thay thế bảo vệ tài khoản CA, DNSSEC hay giám sát Certificate Transparency; giá trị của nó nằm ở việc giảm có chủ đích số đơn vị được phép cấp chứng thư cho tên miền.