Đã xác thực tên miền thành công nhưng hệ thống vẫn từ chối cấp chứng chỉ TLS? Ngoài challenge của ACME, cần kiểm tra một lớp chính sách nằm trong DNS: CAA. Cấu hình này hữu ích để giới hạn bên được phép cấp chứng chỉ, nhưng một thay đổi thiếu rà soát cũng có thể chặn quá trình gia hạn hợp lệ.
Bài viết giải thích CAA cho website công khai và đưa ra quy trình review trước khi thay đổi. Record và hostname bên dưới là minh họa; không có thay đổi DNS hay yêu cầu cấp chứng chỉ thật nào được thực hiện cho bài viết.
1. CAA kiểm soát việc cấp chứng chỉ, không thay thế HTTPS
CAA là viết tắt của Certification Authority Authorization. Chủ tên miền có thể công bố CA được phép cấp chứng chỉ thông qua record DNS; cú pháp và cách xử lý được chuẩn hóa trong RFC 8659.
CAA không tự cấp chứng chỉ, không thay thế xác thực quyền kiểm soát domain và không làm trình duyệt đổi cách kiểm tra chứng chỉ đang được phục vụ. Thay đổi chính sách cũng không phải thao tác thu hồi những chứng chỉ đã được cấp.
Ví dụ một CA nằm trong danh sách được phép vẫn phải hoàn thành quy trình validation riêng. Ngược lại, vượt qua challenge không có nghĩa yêu cầu sẽ được cấp nếu chính sách CAA áp dụng không cho phép.
2. Đọc cấu trúc record trước khi copy
example.com. 3600 IN CAA 0 issue "letsencrypt.org"Trong ví dụ, example.com là tên được cấu hình, 3600 là TTL theo giây, 0 là flags, issue là tag và letsencrypt.org là định danh CA. Đây là ví dụ zone-file; dashboard của nhà cung cấp thường chia dữ liệu thành các ô riêng, nên không dán nguyên dòng vào một ô value.
Tài liệu CAA của Let's Encrypt xác nhận định danh letsencrypt.org. Với CA khác, lấy định danh từ tài liệu chính thức của CA thay vì suy đoán từ tên thương hiệu.
| Tag | Vai trò | Điểm cần nhớ |
|---|---|---|
| issue | Cho phép CA cấp chứng chỉ | Cũng áp dụng cho wildcard nếu không có issuewild tương ứng trong tập chính sách áp dụng |
| issuewild | Chính sách riêng cho wildcard | Cần xem riêng khi yêu cầu chứa tên dạng *.example.com |
| iodef | Chỉ định nơi nhận báo cáo liên quan CAA | Không tự cấp quyền cho CA; không coi việc có record là bảo đảm sẽ nhận mọi cảnh báo |
Không tự bật critical flag chỉ vì muốn cấu hình “mạnh hơn”. Một thuộc tính critical không được CA hiểu có thể ngăn cấp chứng chỉ; cần hiểu đúng khả năng hỗ trợ trước khi sử dụng.
3. Record gần hostname và CNAME có ý nghĩa
CAA ở domain cha có thể chi phối subdomain, nhưng một tập CAA gần tên cần cấp hơn có thể thay thế chính sách kế thừa. Quá trình kiểm tra còn xử lý alias theo quy tắc CAA. Vì vậy, chỉ chụp record của domain gốc chưa đủ để kết luận mọi hostname đang dùng cùng chính sách.
Lập một bảng kiểm kê trước khi sửa: hostname, nơi quản lý DNS, dịch vụ đang cấp chứng chỉ, có wildcard hay không và có CNAME tới nhà cung cấp nào. Với một tổ chức dùng CDN cho website, SaaS cho helpdesk và ACME riêng cho API, mỗi đường cấp phát có thể có yêu cầu khác nhau.
Không thêm CAA cạnh CNAME tại cùng owner name theo cách trái quy tắc DNS. Khi có alias, đọc hướng dẫn của nhà cung cấp và kiểm tra đường phân giải thực tế thay vì cố ép dashboard nhận thêm record.
4. Đừng khóa CDN hoặc SaaS vào một CA đoán trước
Dịch vụ quản lý TLS có thể chọn CA theo sản phẩm và cấu hình. Tài liệu Cloudflare về CAA là một ví dụ về việc cần đối chiếu chính sách với dịch vụ cấp chứng chỉ ở edge.
Trước khi thu hẹp danh sách, hỏi bên quản lý từng dịch vụ: CA nào cần được phép, có cơ chế đổi CA không, certificate có bao nhiêu tên và quy trình renewal được theo dõi ở đâu. Ghi lại câu trả lời có ngày kiểm tra; không dùng một danh sách CA cũ làm quy tắc bất biến.
Giới hạn hẹp nhưng không phù hợp có thể chưa gây lỗi ngay vì chứng chỉ hiện tại vẫn dùng được. Sự cố chỉ lộ ra khi renewal hoặc cấp mới diễn ra. Do đó, “website đang mở bình thường” chưa phải hậu kiểm đầy đủ cho thay đổi CAA.
5. Kiểm tra bằng dig và giữ nguyên thông tin chẩn đoán
Trên máy có BIND dig, truy vấn loại CAA và xem cả status, server trả lời, ANSWER cùng AUTHORITY. Cú pháp được mô tả trong tài liệu dig của ISC:
dig example.com. CAA
dig api.example.com. CAA
dig api.example.com. CNAME
dig example.com. NS
dig @ns1.example.com. example.com. CAA +norecurseThay ns1.example.com bằng authoritative server thật của zone. Lặp kiểm tra với từng server được công bố để tìm sự không đồng nhất. Những lệnh này là truy vấn đọc; không sửa DNS.
Không suy luận “không có chính sách” chỉ vì truy vấn CAA tại hostname có ANSWER rỗng: còn phải xem status, alias và chính sách có thể áp dụng ở tên cha. SERVFAIL hoặc timeout cũng không tương đương một câu trả lời hợp lệ cho biết không có record.
Khi gặp lỗi cấp chứng chỉ, lưu hostname chính xác, thời điểm, CA yêu cầu, mã lỗi ACME và response DNS. Nếu cần chia sẻ log, che credential và dữ liệu nhạy cảm trước khi gửi.
6. Một quy trình thay đổi có thể review
- Kiểm kê mọi đường cấp phát và renewal cho domain cùng subdomain liên quan.
- Ghi lại tập record cũ, TTL, người sở hữu thay đổi và phương án khôi phục.
- Soạn chính sách mới theo tài liệu hiện tại của CA/CDN/SaaS; review riêng wildcard và alias.
- Thử ở môi trường kiểm thử phù hợp, hiểu rõ giới hạn của staging so với production.
- Sau thay đổi, kiểm tra authoritative DNS, resolver và workflow cấp phát hợp lệ.
- Theo dõi renewal cùng cảnh báo hạn chứng chỉ; không chờ gần ngày hết hạn mới thử.
Khôi phục record cũ cũng cần thời gian phản ánh qua cache. Vì vậy, chuẩn bị trước cửa sổ thay đổi và người xử lý sự cố sẽ hữu ích hơn việc chỉ ghi “rollback bằng cách xóa CAA”.
7. Checklist bàn giao vận hành
- Mỗi hostname có người chịu trách nhiệm chứng chỉ và đường renewal rõ ràng.
- Chính sách cho wildcard được review riêng.
- Không có xung đột với CNAME hoặc các dịch vụ quản lý TLS.
- DNS trả lời đúng và không còn lỗi truy vấn chưa được giải thích.
- Có bằng chứng kiểm tra cấp phát/renewal, không chỉ ảnh website đang hoạt động.
- Cảnh báo sắp hết hạn và bản sao cấu hình trước thay đổi đã sẵn sàng.
CAA phát huy tác dụng khi đi cùng kiểm kê domain và vận hành chứng chỉ. Hãy coi đây là một chính sách cấp phát cần bảo trì theo dịch vụ thực tế, thay vì một record bảo mật thêm một lần rồi quên.
Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.