Cài Certbot cho Apache trên Ubuntu 24.04

Bạn sẽ xây dựng gì

Một website Apache trên Ubuntu 24.04, phản hồi qua HTTPS bằng chứng chỉ Let's Encrypt miễn phí được trình duyệt tin cậy. Certbot cấp chứng chỉ này và một systemd timer tự động gia hạn mà bạn không cần quan tâm thêm. Lệnh thực hiện việc này chỉ có một dòng. Mọi lỗi đều xảy ra trước dòng lệnh đó: vhost không có ServerName, cổng 80 bị firewall của nhà cung cấp chặn, hoặc DNS vẫn trỏ đến server cũ. Vì vậy, phần lớn nội dung của hướng dẫn này tập trung vào các điều kiện tiên quyết và nêu chính xác chuỗi lỗi mà từng sai sót in ra.

Có 2 lưu ý về phạm vi. Nếu web server của bạn là nginx, quy trình có cấu trúc tương tự nhưng plugin và các file cấu hình khác nhau; hãy dùng phiên bản hướng dẫn này cho nginx. Nếu dịch vụ cần bảo vệ chỉ dùng nội bộ, chẳng hạn một admin panel trên địa chỉ private hoặc một staging box không có người khác truy cập, bạn không cần certificate authority; self-signed certificate cần ít cấu hình hơn và hoạt động offline.

Điều kiện cần và ba cách lỗi xảy ra trước cả khi Certbot chạy

• Apache đã phục vụ site của bạn qua HTTP không mã hóa. Plugin Apache của Certbot chỉnh sửa site hiện có; nó không tạo site mới. Nếu bạn bắt đầu với một VPS trống, trước tiên hãy dựng LAMP stack trên Ubuntu 24.04 rồi quay lại. Hướng dẫn này là phần TLS còn thiếu của LAMP stack đó.
• Một domain public có bản ghi A trỏ đến địa chỉ VPS. Thử thách HTTP-01 của Let's Encrypt yêu cầu các máy chủ xác thực của họ kết nối đến máy chủ của bạn từ Internet: homelab nằm sau NAT mà không có port forward sẽ không dùng được, và các tên .local cũng không dùng được. HTTP-01 có thể xác thực một IP trần, nhưng Let's Encrypt chỉ cấp certificate cho IP trên profile shortlived phải đăng ký tham gia (thời hạn 160 giờ), còn Certbot 2.9.0 trong apt không thể yêu cầu ACME profile hoặc địa chỉ IP. Vì vậy, hướng dẫn này cần một domain. dig +short example.com phải trả về địa chỉ VPS của bạn. Nếu bạn vừa thay đổi DNS trong giờ vừa qua, hãy chờ TTL của bản ghi cũ hết hạn rồi mới cấp certificate.
• Nếu có bản ghi AAAA, bản ghi đó phải chính xác. Let's Encrypt luôn thử IPv6 trước khi một bản ghi AAAA được công bố. Nếu kết nối bị timeout, hệ thống sẽ thử lại qua IPv4, nhưng các lỗi khác không được thử lại lần thứ hai: một bản ghi AAAA trỏ đến địa chỉ từ chối kết nối, hoặc đến một server đang hoạt động nhưng không phải server này, sẽ làm xác thực thất bại ngay cả khi curl trên laptop của bạn, nhiều khả năng đang dùng IPv4, vẫn hoạt động bình thường. Hãy công bố một bản ghi AAAA chính xác hoặc không công bố bản ghi nào.

Cả cổng 80 và 443 đều phải được mở trong ufw và trong firewall mạng của nhà cung cấp. Hầu hết control panel hosting có thêm một firewall mà hệ điều hành không nhìn thấy. HTTP-01 xác thực cụ thể qua cổng 80; bạn không thể chạy quy trình này chỉ với cổng 443.

sudo ufw allow "Apache Full"
sudo ufw status

Khi các điều kiện trên đã sẵn sàng, toàn bộ công việc chỉ mất mười lăm phút, trong đó mười phút là để đọc.

Dùng Certbot từ Snap hay apt? Trên 24.04, apt cuối cùng đã ổn

Certbot chuyển sang phân phối bằng snap từ nhiều năm trước vì một lý do chính đáng: các package của distro bị đóng băng quá lâu. Ubuntu 20.04 đi kèm Certbot 0.40 và không bao giờ cập nhật tiếp, còn dự án đã mất kiên nhẫn với việc debug các bug tồn tại 5 năm. Trên 24.04, lý do đó không còn nữa. Archive cung cấp Certbot 2.9.0, bản release tháng 2 năm 2024 thuộc dòng 2.x hiện đại, và unattended-upgrades cài mọi bản cập nhật bảo mật mà Ubuntu phát hành cho package này. Upstream sau đó đã chuyển sang dòng 5.x, nhưng guide này không cần các tính năng đó. Khuyến nghị của tôi cho OS này là dùng apt. Bạn không cần chạy daemon snapd, plugin Apache được cài trong cùng một transaction, và timer gia hạn tích hợp với systemd theo cách thông thường của Debian.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Kết quả đúng là: certbot 2.9.0. Package python3-certbot-apache là plugin đọc và chỉnh sửa các config Apache của bạn. Nếu thiếu plugin này, certbot --apache sẽ fail với The requested apache plugin does not appear to be installed.

Snap vẫn là lựa chọn phù hợp trong 2 trường hợp: bạn muốn dùng Certbot mới nhất ngay khi bản release được phát hành, hoặc bạn cần một DNS plugin chỉ được phân phối dưới dạng snap (một số plugin của các provider certbot-dns-* thuộc nhóm này). Nếu chọn cách đó:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Dù chọn cách nào, không bao giờ chạy đồng thời cả 2. 2 bản cài đặt sẽ khiến 2 renewal scheduler tranh nhau quản lý /etc/letsencrypt, và certbot mà shell tìm thấy trong PATH có thể không phải là bản đang quản lý các certificate của bạn. Dòng apt remove ở trên không phải phần trang trí tùy chọn.

Vhost mà Certbot chỉnh sửa phải tồn tại từ trước, ServerName quyết định tất cả

certbot --apache hoạt động bằng cách tìm virtual host trên cổng 80 có ServerName hoặc ServerAlias khớp với từng domain -d bạn truyền vào. Sau đó, nó xác minh quyền kiểm soát domain thông qua virtual host này rồi tạo một bản sao SSL của vhost đó. Không có ServerName khớp thì không thể khớp. Ubuntu cũng cài sẵn 000-default.conf với ServerName bị comment. Một dòng bị comment này là nguyên nhân phổ biến nhất khiến lệnh lớn trong hướng dẫn này thất bại.

Vì vậy, trước khi chạy Certbot, hãy tạo một vhost dùng đúng tên của site. Tạo /etc/apache2/sites-available/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Enable vhost này rồi xác nhận Apache phân tích được cấu hình và định tuyến hostname đến đúng vhost:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest phải in ra Syntax OK. Nếu lệnh cũng in ra AH00558: apache2: Could not reliably determine the server's fully qualified domain name thì đó là cảnh báo về ServerName toàn cục, không phải vhost của bạn. Cảnh báo này không gây ảnh hưởng trong trường hợp này và có thể tắt bằng echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2.

Kết quả của -S mới là phần cần kiểm tra. Bạn cần thấy một dòng như port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) với alias www.example.com bên dưới. Apache báo symlink sites-enabled mà nó thực sự đã đọc, không phải file bạn chỉnh sửa trong sites-available. Nếu example.com không được liệt kê trên cổng 80 thì Certbot cũng sẽ không tìm thấy vhost đó.

Cấp chứng chỉ: certbot --apache

sudo certbot --apache -d example.com -d www.example.com

Lần chạy đầu tiên sẽ hỏi 3 thông tin: địa chỉ email (Let's Encrypt không còn lưu địa chỉ này cùng ACME account và cũng không còn gửi cảnh báo sắp hết hạn, nên bạn phải tự monitor việc renew), đồng ý với điều khoản của Let's Encrypt và có chia sẻ email với EFF hay không. Certbot không còn hỏi về redirect: từ Certbot 1.0, Apache installer mặc định redirect HTTP sang HTTPS (câu hỏi này bị bỏ từ 1.4), đúng với nhu cầu thông thường. Truyền --no-redirect nếu bạn thực sự cần tiếp tục phục vụ nội dung qua plain HTTP.

Kết quả thành công sẽ giống như sau. Bạn nên đọc kỹ thay vì chỉ lướt qua:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2027-01-09.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Đằng sau thông báo đó, Certbot đã thực hiện 4 việc: bật module ssl của Apache nếu module này chưa được bật, ghi example.com-le-ssl.conf — một bản sao của vhost vào *:443 cùng với SSLEngine on và các đường dẫn đến certificate — bật vhost này, rồi thêm block RewriteRule vào vhost port 80 ban đầu để redirect toàn bộ request sang HTTPS bằng mã 301. File vhost ban đầu được chỉnh sửa, không bị thay thế. Bản sao SSL nằm ngay bên cạnh để bạn có thể đọc từng dòng mà Certbot đã thêm.

Vị trí thực sự của certificate và lý do bạn không bao giờ copy nó

Mọi thứ đều nằm trong /etc/letsencrypt/live/example.com/: fullchain.pem (certificate cùng intermediate chain, là tệp các server nên trỏ đến), privkey.pem (private key, chỉ root được phép đọc), cùng với cert.pem và chain.pem dành cho phần mềm cần các thành phần này ở dạng tách riêng. Đây là các symlink trỏ vào /etc/letsencrypt/archive/. Cơ chế liên kết này phục vụ việc gia hạn: khi gia hạn, hệ thống ghi các tệp mới vào archive/ rồi cập nhật symlink. Hãy trỏ mọi phần mềm khác vào các đường dẫn live/ để chúng tự nhận certificate mới sau mỗi lần gia hạn; nếu copy các tệp sang nơi khác, bạn sẽ tự tạo ra một sự cố ngừng dịch vụ sau 90 ngày.

Tệp còn lại cần biết là /etc/letsencrypt/renewal/example.com.conf. Tệp này ghi lại certificate được cấp như thế nào, gồm authenticator = apache, installer = apache và các domain, để quá trình gia hạn có thể lặp lại tự động mà không cần thao tác thủ công, bao gồm cả việc reload Apache sau đó.

Gia hạn đã được lập lịch, hãy xác minh, không tạo lại

Chứng chỉ Let's Encrypt hiện có thời hạn 90 ngày theo thiết kế, và gói apt đã cài sẵn cơ chế cần thiết: một systemd timer chạy Certbot 2 lần mỗi ngày vào các thời điểm ngẫu nhiên, gia hạn mọi chứng chỉ còn không quá 30 ngày trước khi hết hạn. Không thêm cron job bên cạnh; scheduler thứ hai không mang lại lợi ích gì ngoài log dư thừa và nguy cơ chạm rate limit. Let's Encrypt đã thông báo rằng từ ngày 10 tháng 2 năm 2027, chứng chỉ mới sẽ mặc định có thời hạn 64 ngày. Cửa sổ 30 ngày vẫn hoạt động với các chứng chỉ này; việc gia hạn chỉ diễn ra khoảng ngày 34 thay vì ngày 60, nên không cần thay đổi gì trên server này.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

Lệnh đầu tiên cho biết timer đang active, với thời điểm NEXT nằm trong 24 giờ tới. Lịch chạy 2 lần mỗi ngày và có độ trễ ngẫu nhiên, nên thời điểm chính xác được cố ý làm cho không thể đoán trước (trên bản cài đặt snap, timer là snap.certbot.renew.timer). Dry run thực hiện đầy đủ quy trình diễn tập gia hạn với môi trường staging của Let's Encrypt, dùng challenge thật nhưng không phát hành chứng chỉ và không tiêu tốn rate limit. Kết quả đúng kết thúc bằng:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Nếu dry run thất bại, lần gia hạn thật sau khoảng 60 ngày cũng sẽ thất bại theo cùng cách. Hãy sửa ngay khi chứng chỉ hiện tại vẫn còn gần như toàn bộ thời hạn sử dụng. Nguyên nhân thường gặp là một firewall rule được thêm sau khi cấp chứng chỉ, rồi lại đóng port 80.

Kiểm tra bằng curl và nội dung biểu tượng ổ khóa phải hiển thị

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

Lệnh thứ nhất phải trả về HTTP/1.1 301 Moved Permanently cùng header Location: https://example.com/. Đây là redirect do Certbot cài đặt. Lệnh thứ hai phải trả về HTTP/1.1 200 OK và curl không báo lỗi TLS. Lệnh thứ ba in ra issuer, một dòng O = Let's Encrypt với CN ngắn như YE1 hoặc YE2 (khóa ECDSA), hoặc YR1 hoặc YR2 (khóa RSA), và notAfter còn hạn khoảng 90 ngày. Certificate được cấp trước khi Let's Encrypt ngừng dùng các intermediate cũ vẫn có thể hiển thị CN như R12 hoặc E7 cho đến lần renewal tiếp theo. Đây không phải lỗi. Trong trình duyệt, bạn sẽ thấy biểu tượng ổ khóa. Khi bấm vào đó, issuer hiển thị phải giống như trên. Nếu curl hoạt động nhưng trình duyệt cảnh báo, gần như chắc chắn bạn đang xem một trang trong cache hoặc dùng sai hostname, không phải gặp vấn đề với certificate.

Nhiều site: một chứng chỉ SAN hay mỗi site một chứng chỉ

Cả hai cách đều hoạt động và được gia hạn theo cùng một cách. Với các site không liên quan trên cùng một máy, hãy chạy lệnh cấp chứng chỉ một lần cho mỗi site. Mỗi site sẽ có thư mục riêng bên dưới live/ và cấu hình gia hạn riêng. Sự cố ở một domain sẽ không bao giờ chặn việc gia hạn các domain khác. Đây là lựa chọn mặc định của tôi.

Với một site có nhiều tên, hãy đặt các tên đó vào một chứng chỉ SAN. Một chứng chỉ có thể chứa tối đa 100 tên. Bạn đã thực hiện việc này ở trên với example.com và www.example.com. Sau này, để thêm một tên vào chứng chỉ hiện có, hãy cấp lại chứng chỉ bằng cách chỉ định tên chứng chỉ và toàn bộ danh sách mới:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot nhận thấy tập domain đã thay đổi, yêu cầu bạn xác nhận việc mở rộng rồi thay thế chứng chỉ tại chỗ, vẫn dùng đường dẫn live/. Vì vậy, không cần thay đổi gì khác. Lưu ý rằng danh sách mới thay thế danh sách cũ, không phải bổ sung vào danh sách cũ: nếu bỏ www khỏi lệnh đó, chứng chỉ mới sẽ âm thầm loại bỏ tên này.

Wildcard cần DNS-01, nhưng thường bạn không cần wildcard

HTTP-01 không thể cấp *.example.com. Đặt một file trên web server chỉ chứng minh bạn kiểm soát một hostname, không phải toàn bộ namespace. Wildcard yêu cầu challenge DNS-01: Certbot đặt một bản ghi TXT tại _acme-challenge.example.com. Trên thực tế, bạn cần một plugin certbot-dns-* có API credentials của nhà cung cấp DNS, hoặc phải tự sửa bản ghi TXT mỗi lần gia hạn bằng --manual (rất bất tiện, không nên dựa vào cách này). Hướng dẫn đầy đủ, từ cơ chế bản ghi TXT đến plugin tự động gia hạn mà không cần can thiệp, có tại chứng chỉ wildcard với Certbot qua DNS-01. Khuyến nghị thực tế: nếu bạn có 4 subdomain đã biết, chứng chỉ SAN liệt kê cả 4 subdomain sẽ đơn giản hơn wildcard và không cần để DNS API key trên server.

Các tình huống lỗi và chuỗi bạn sẽ thấy

Certbot từ chối khởi động vì cấu hình của Apache bị lỗi.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

Plugin chạy configtest trước khi thực hiện bất kỳ thao tác nào và dừng lại nếu chính Apache gặp lỗi. Các \n là giá trị literal vì Certbot in ra repr của exception. Tự chạy sudo apache2ctl configtest: lệnh này cho biết file và dòng bị lỗi. Nguyên nhân thường là lỗi gõ khi chỉnh sửa thủ công, SSLCertificateFile trỏ đến path không còn tồn tại, hoặc module được tham chiếu nhưng chưa enable. Sửa cho đến khi lệnh in ra Syntax OK, rồi chạy lại Certbot.

Không có vhost nào khớp với domain.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Đây là lỗi thiếu ServerName đã đề cập trước đó, xảy ra tại thời điểm cấp chứng chỉ. Certbot đã tìm trong mọi vhost trên port 80 đang được enable một ServerName/ServerAlias khớp với -d của bạn nhưng không tìm thấy. sudo apache2ctl -S cho biết Apache thực sự đang định tuyến như thế nào. Thêm dòng ServerName vào đúng vhost, reload rồi thử lại. Một trường hợp gần giống là quá trình validation đi vào sai vhost và response của challenge trả về Invalid response ... 404 vì một site khác đã nhận request. Cách chẩn đoán và công cụ vẫn giống nhau: apache2ctl -S.

Validation bị timeout.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let's Encrypt không thể mở kết nối TCP đến port 80 tại địa chỉ mà DNS của bạn công bố. Theo mức độ thường gặp: firewall mạng của nhà cung cấp (tách biệt với ufw và được cấu hình trong hosting panel), ruleset của ufw chỉ cho phép 443 hoặc chỉ cho phép SSH, hoặc DNS vẫn trỏ đến server cũ. Chỉ một bản ghi AAAA cũ thường không gây ra lỗi này, vì khi lần thử qua IPv6 bị timeout, Let's Encrypt sẽ thử lại qua IPv4. Lỗi AAAA thường xuất hiện dưới dạng Connection refused hoặc Invalid response từ sai server. Hãy kiểm tra từ bên ngoài VPS: curl -I http://example.com trên laptop sẽ tái hiện những gì validator của họ nhìn thấy.

Bạn đã retry đến mức bị rate limit.

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let's Encrypt cho phép 5 lần validation thất bại trên mỗi hostname, mỗi account, mỗi giờ. Cơ chế này giống một bucket tự bổ sung, hoàn lại khoảng một lần retry mỗi 12 phút. Retry liên tục khi firewall bị lỗi sẽ nhanh chóng dùng hết hạn mức. Chờ sẽ giải quyết tạm thời, nhưng cách sửa đúng là thay đổi quy trình: sau mỗi lần thất bại, hãy debug bằng staging environment cho đến khi thành công.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

Lưu ý certonly: chỉ --dry-run được chấp nhận bởi các subcommand certonly và renew. Dạng certbot --apache --dry-run không có thêm tùy chọn sẽ từ chối chạy và báo --dry-run currently only works with the 'certonly' or 'renew' subcommands. Dry run thực hiện validation với staging. Môi trường này có hạn mức rộng hơn và không cấp certificate thật, nên bạn có thể thử lỗi nhiều lần. Chỉ chạy lại command thật sau khi staging đã thành công. Các hạn mức khác, gồm 50 certificate trên mỗi registered domain mỗi tuần và 5 certificate trùng cùng một name set mỗi tuần, chỉ thường gặp khi một script liên tục cấp lại certificate trong loop.

Sau khi HTTPS hoạt động, hãy nhớ certificate chỉ bảo vệ transport, không bảo vệ server. Port 22 vẫn có thể nhận các lần đoán password cả ngày. Kết hợp với Cài Fail2ban trên Ubuntu 24.04 là bước tiếp theo hợp lý trong 30 phút tới.

FAQ

Tôi nên cài Certbot bằng snap hay apt cho Apache trên Ubuntu 24.04?

Dùng apt. Ubuntu 24.04 phát hành Certbot 2.9.0, đủ mới cho mọi nội dung trong hướng dẫn này, nhận các bản cập nhật bảo mật Ubuntu phát hành qua unattended-upgrades và không cần snapd. Chỉ chọn snap nếu bạn cần ngay bản phát hành mới nhất hoặc một DNS plugin chỉ được phân phối dưới dạng snap. Nếu chuyển sang snap, trước tiên hãy dùng apt remove certbot python3-certbot-apache để hai scheduler gia hạn không chạy đồng thời.

Tại sao Certbot báo "Unable to find a virtual host listening on port 80"?

Vì không có vhost cổng 80 nào đang được enable có ServerName hoặc ServerAlias khớp với domain bạn truyền bằng -d. Vhost mặc định của Ubuntu được phát hành với ServerName đang bị comment. Chạy sudo apache2ctl -S, tìm hoặc tạo vhost sẽ quản lý hostname đó, thêm ServerName example.com, reload Apache rồi chạy lại Certbot.

Làm cách nào để sửa lỗi "Timeout during connect (likely firewall problem)"?

Let's Encrypt không thể truy cập cổng 80 tại địa chỉ mà DNS của bạn công bố. Kiểm tra firewall mạng ở panel của nhà cung cấp cũng như ufw. Xác nhận dig +short example.com trả về VPS này. Sửa hoặc xóa bản ghi AAAA cũ, vì quá trình xác thực thử IPv6 trước và chỉ chuyển sang IPv4 sau khi timeout. Xác nhận bản sửa từ bên ngoài server bằng curl -I http://example.com, rồi chạy thử bằng sudo certbot certonly --apache --dry-run -d example.com trước khi cấp chứng chỉ thật.

Certbot có tự động gia hạn chứng chỉ trên Ubuntu 24.04 không?

Có. Gói apt cài certbot.timer, một systemd timer chạy 2 lần mỗi ngày và gia hạn mọi chứng chỉ còn không quá 30 ngày trước khi hết hạn, sau đó reload Apache. snap dùng snap.certbot.renew.timer cho cùng tác vụ. Kiểm tra bằng systemctl list-timers certbot.timer và chạy thử bằng sudo certbot renew --dry-run. Không thêm cron job riêng.

Làm cách nào để lấy wildcard certificate bằng Certbot và Apache?

Wildcard certificate yêu cầu challenge DNS-01. Certbot phải tạo bản ghi TXT tại _acme-challenge.example.com. Vì vậy cần một certbot-dns-* plugin có API credentials cho DNS provider của bạn. Phương án --manual yêu cầu sửa thủ công bản ghi TXT ở mỗi lần gia hạn. Nếu bạn chỉ có một số ít subdomain đã biết, SAN certificate liệt kê rõ từng subdomain sẽ đơn giản hơn và giúp giữ DNS API key ngoài server.