Hướng dẫn · 16/10/2026

ACME DNS-01: Tự động cấp và gia hạn wildcard TLS an toàn

ACME DNS-01 chứng minh quyền kiểm soát tên miền bằng một TXT record tạm thời tại _acme-challenge. Đây là challenge phổ biến để cấp wildcard certificate và certificate cho dịch vụ không mở Internet. Nhưng nếu automation giữ API token có quyền sửa toàn bộ DNS, một lỗ hổng trên máy cấp chứng chỉ có thể trở thành sự cố chiếm quyền tên miền. Thiết kế production phải tách zone validation, giới hạn credential, xử lý propagation bằng truy vấn thật và giám sát renewal từ đầu đến cuối.

ACME DNS-01 chứng minh quyền kiểm soát tên miền bằng một TXT record tạm thời tại _acme-challenge. Đây là challenge phổ biến để cấp wildcard certificate và certificate cho dịch vụ không mở Internet. Nhưng nếu automation giữ API token có quyền sửa toàn bộ DNS, một lỗ hổng trên máy cấp chứng chỉ có thể trở thành sự cố chiếm quyền tên miền. Thiết kế production phải tách zone validation, giới hạn credential, xử lý propagation bằng truy vấn thật và giám sát renewal từ đầu đến cuối.

Bài viết dựa trên tài liệu chính thức của Let’s Encrypt về ACME challenge, CAA account/method binding và rate limits. Ví dụ dùng Let’s Encrypt để minh họa; cú pháp và khả năng delegation của ACME client/DNS provider cần được kiểm tra riêng.

1. DNS-01 chứng minh điều gì?

CA đưa một token cho ACME client. Client kết hợp token với ACME account key, tạo giá trị challenge và publish TXT tại:

_acme-challenge.example.com.  IN TXT  "<challenge-value>"

CA truy vấn DNS; nếu giá trị khớp, authorization thành công. Chứng minh này cho phép cấp certificate cho identifier đang yêu cầu, không chứng minh web server an toàn hoặc private key được bảo vệ tốt.

DNS-01 cần quyền sửa DNS trong mỗi lần cấp/gia hạn. Vì vậy chỉ nên dùng tự động với provider có API phù hợp. Thao tác thủ công dễ bị quên khi certificate hết hạn và không phải quy trình production bền vững.

2. Wildcard không bao phủ apex domain

*.example.com bao phủ một cấp như api.example.com, nhưng không bao phủ example.com và thường không bao phủ tên nhiều cấp như a.b.example.com. Nếu cần cả apex và wildcard, yêu cầu cả hai Subject Alternative Names:

example.com
*.example.com

Hai authorization có thể dùng cùng owner name _acme-challenge.example.com nhưng giá trị TXT khác nhau. Automation phải hỗ trợ nhiều TXT cùng tên; không xóa/ghi đè giá trị của challenge khác đang chạy.

3. Tách challenge zone khỏi DNS chính

Tài liệu Let’s Encrypt cho phép dùng CNAME hoặc NS delegation vì validation tuân theo DNS lookup. Mô hình an toàn hơn:

_acme-challenge.example.com. CNAME \
  example-com.acme-validation.example.net.

ACME automation chỉ có quyền ghi TXT trong zone validation, không có quyền đổi A/AAAA/MX/NS của domain chính. Một số client/provider có cách theo CNAME hoặc delegated zone khác nhau; kiểm thử cả issue, renew và cleanup trước khi áp dụng.

NS delegation cho subzone cũng khả thi nhưng tạo một authority boundary riêng cần vận hành DNSSEC, availability và access control đúng. Không tạo chuỗi CNAME dài hoặc loop.

4. Least privilege cho DNS credential

Chỉ cấp quyền create/read/delete TXT trong challenge zone hoặc owner name cần thiết.
Không cấp quyền thay nameserver, transfer zone, sửa mail hoặc record website.
Mỗi môi trường/tenant dùng identity riêng để giảm blast radius.
Lưu secret trong secret manager; không để trong image, repository hay command line log.
Giới hạn network/source identity nếu provider hỗ trợ.
Audit mọi thay đổi DNS và rotation credential định kỳ.

Nếu provider chỉ cung cấp token toàn quyền, đặt automation trong một service cô lập và cân nhắc chuyển riêng challenge delegation sang provider hỗ trợ scope hẹp.

5. Propagation không nên là một lệnh sleep cố định

API báo tạo TXT thành công không có nghĩa authoritative nameserver đã trả record. DNS có replication nội bộ, anycast, cache và negative caching. Ngược lại, đợi một khoảng quá dài cố định làm renewal chậm không cần thiết.

Đọc danh sách authoritative nameserver của challenge name.
Truy vấn từng authority cho đúng TXT value.
Chỉ báo CA bắt đầu validation khi mọi authority cần thiết đã hội tụ.
Áp deadline và backoff; nếu hết hạn, cleanup rồi báo lỗi rõ.

dig +short NS example.net
dig +short TXT example-com.acme-validation.example.net \
  @<authoritative-nameserver>

Truy vấn recursive resolver công cộng có ích để chẩn đoán nhưng không thay cho việc hiểu authoritative state. TTL thấp giúp thay đổi nhanh hơn nhưng không loại bỏ negative cache đã tồn tại.

6. Concurrency và cleanup phải sở hữu theo giá trị

Nhiều order có thể cùng đặt TXT tại một owner name. Thao tác “replace toàn bộ RRset” hoặc “xóa record sau khi xong” dễ phá challenge khác. State của job phải lưu zone, owner name, exact TXT value, order/authorization ID và thời điểm tạo.

Khi cleanup, chỉ xóa giá trị job sở hữu. Nếu DNS API thao tác ở cấp RRset, dùng read-modify-write có concurrency control hoặc serialize theo owner name. Job crash cần reconciler dọn challenge cũ sau một TTL vận hành, nhưng không được xóa challenge còn active chỉ dựa vào tuổi.

7. Dùng staging trước production

ACME CA có rate limit để chống lạm dụng và vòng lặp lỗi. Trong lúc phát triển:

dùng staging directory của CA;
test sai credential, DNS timeout và propagation chậm;
không retry order mới liên tục khi một authorization lỗi;
reuse certificate/order hợp lệ khi thích hợp;
chuyển production chỉ sau khi issue + deploy + renew simulation đạt.

Alert theo lỗi gốc. Một cron chạy mỗi phút không sửa được CNAME sai mà chỉ tiêu tốn rate-limit budget và tạo thêm TXT rác.

8. CAA giảm phạm vi cấp nhầm

CAA giới hạn CA được phép cấp. Với Let’s Encrypt, identifier CA là letsencrypt.org. issuewild áp dụng cho wildcard; nếu không có issuewild, quy tắc issue liên quan vẫn cần được hiểu theo CAA processing.

example.com. CAA 0 issue \
  "letsencrypt.org; validationmethods=dns-01"
example.com. CAA 0 issuewild \
  "letsencrypt.org; validationmethods=dns-01"

CA hỗ trợ RFC 8657 có thể dùng accounturi để khóa issuance vào ACME account cụ thể. CAA là defense in depth, không thay DNS/API security; cấu hình sai có thể chặn renewal. Kiểm tra CAA ở apex, parent inheritance, CNAME target và DNSSEC behavior trước rollout.

9. ACME account key và certificate key là hai tài sản khác nhau

Tài sản	Vai trò	Kiểm soát
ACME account key	Ký request/order với CA	Backup, giới hạn access, rotation/recovery runbook
DNS API credential	Publish challenge	Scope hẹp, audit, secret manager, TTL/rotation
Certificate private key	Chứng minh identity TLS	Không export nếu dùng KMS/HSM; permission chặt
Certificate chain	Public identity material	Phân phối/version và reload đúng

Không dùng một secret bundle chia sẻ cho mọi môi trường. Việc mất account key và mất certificate private key có quy trình xử lý khác nhau; tài liệu incident response phải phân biệt.

10. Deploy certificate phải atomic và có xác minh

Issuance thành công chưa có nghĩa dịch vụ đang dùng certificate mới. Pipeline cần:

xác minh SAN, issuer, validity window và key khớp certificate;
ghi file/version mới bằng atomic rename hoặc secret version;
reload workload theo cách không làm rớt traffic;
probe TLS từ bên ngoài và đọc serial/notAfter thực tế;
chỉ đánh dấu deployment thành công sau verification.

Không ghi đè private key/certificate đang hoạt động từng file một rồi reload giữa chừng. Với nhiều replica, theo dõi version trên từng endpoint để phát hiện node chưa nhận bản mới.

11. Renewal phải chạy sớm và có nhiều cơ hội retry

Không đợi sát ngày hết hạn. Chạy scheduler thường xuyên, nhưng chỉ renew khi vào renewal window của client. Dùng jitter để nhiều certificate không đồng loạt gọi DNS/CA. Lock theo certificate lineage để tránh hai instance cùng renew.

Metric/alert tối thiểu:

ngày còn lại của certificate đang phục vụ;
thời điểm renewal thành công gần nhất;
issue/authorization/deploy failure theo nguyên nhân;
DNS propagation duration và TXT orphan count;
serial/version trên từng endpoint;
credential/account-key rotation age.

Alert theo nhiều ngưỡng, ví dụ cảnh báo sớm để sửa và cảnh báo khẩn cấp khi chỉ còn ít ngày. Kiểm tra certificate từ đường người dùng, không chỉ đọc file local.

12. Failure drill cần thực hiện

DNS provider API unavailable hoặc trả throttling.
Một authoritative nameserver trả TXT cũ.
Hai wildcard order chạy đồng thời trên cùng owner name.
Job crash sau create nhưng trước cleanup.
CAA bị thay sai hoặc ACME account key mất.
Issuance thành công nhưng reload service thất bại.
Certificate bị revoke và cần thay khẩn cấp.

Runbook phải nêu owner, quyền break-glass, audit và cách quay lại certificate còn hợp lệ. Không tắt xác minh TLS hoặc xóa CAA vĩnh viễn chỉ để renewal chạy lại.

Checklist production

Wildcard và apex được yêu cầu như hai SAN khi cần cả hai.
_acme-challenge được delegate sang validation zone nếu có thể.
DNS credential chỉ sửa TXT trong scope tối thiểu.
Automation hỗ trợ nhiều TXT value và cleanup theo ownership.
Propagation được xác minh trên authoritative DNS, không sleep mù.
Staging đã test issue, cleanup, deploy và renew.
CAA giới hạn CA/method/account theo khả năng hỗ trợ đã kiểm chứng.
Account key, DNS token và certificate key được quản lý tách biệt.
Deploy atomic, reload có kiểm tra certificate từ bên ngoài.
Alert expiration, renewal failure, DNS orphan và endpoint version đã bật.

Kết luận

DNS-01 giải quyết wildcard và hệ thống không thể dùng HTTP-01, nhưng đổi lại nó đặt DNS credential vào critical path của certificate. Delegation challenge zone, quyền tối thiểu, propagation có kiểm chứng, cleanup an toàn và deployment được probe biến một script cấp chứng chỉ thành hệ thống renewal có thể tin cậy—mà không trao chìa khóa toàn bộ DNS cho mỗi web server.