Cài đặt chứng chỉ TLS (HTTPS) bằng Certbot cho NGINX và tự động gia hạn

Phạm vi thực hành: Ubuntu 24.04 LTS trên VPS thử nghiệm độc lập; tên miền lab lab-cf02.localhost.vn. Chỉ thao tác trên tài sản thuộc quyền quản lý của bạn. Máy chủ lab sử dụng gói Certbot cài từ kho apt chuẩn của Ubuntu; phần báo cáo cuối bài ghi nhận chi tiết kết quả cấp mới chứng chỉ, chạy thử gia hạn (dry-run) và xác minh kết nối HTTPS vào ngày 30/09/2026, kèm theo ảnh chụp đối chiếu trạng thái systemd timer/service ngày 01/10. Đợt rà soát ngày 01/10 chỉ đọc trạng thái lịch chạy chứ không ép cấp lại chứng chỉ hay chạy lại lệnh dry-run. Các phần phân tích về gói snap, tên miền phụ www, chế độ Cloudflare Proxy và phương án khôi phục (rollback) đóng vai trò kiến thức hướng dẫn mở rộng cho bạn đọc.

Có một nguyên tắc an toàn mà bất kỳ đàn anh kỹ thuật nào cũng sẽ nhắc đi nhắc lại: hãy xin cấp chứng chỉ TLS cho NGINX trước khi bạn gõ bất kỳ ký tự mật khẩu quản trị WordPress nào đi qua mạng Internet. Bạn hoàn toàn không cần phải cài xong xuôi WordPress rồi mới đi lo chuyện bảo mật đường truyền; chỉ cần tên miền của bạn đang trỏ đúng về VPS và phục vụ một trang HTML tĩnh đơn giản là đã đủ điều kiện để gọi Certbot lấy chứng chỉ HTTPS, sau đó mới ung dung mở trình cài đặt WordPress ở bài 37 qua kết nối đã mã hóa an toàn. Dù thứ tự đánh số bài viết trong chuỗi sổ tay như thế nào, ngoài đời thực bạn tuyệt đối không nên đăng nhập quản trị qua giao thức HTTP trần trụi.

Danh sách điều kiện cần trước khi gõ lệnh

Trước khi bắt tay vào xin chứng chỉ, bạn cần chuẩn bị sẵn 5 mảnh ghép cơ bản: một tên miền (hoặc subdomain) thuộc quyền quản lý của bạn, bản ghi DNS loại A (và AAAA nếu dùng IPv6) đã trỏ chính xác về địa chỉ IP của VPS, khối cấu hình server block (Virtual Host) trong NGINX đã khai báo đúng server_name đó, cổng mạng TCP 80 đang mở thông suốt từ ngoài Internet vào máy chủ, và tài khoản người dùng có quyền sudo. Trong bài hướng dẫn này, chúng ta sử dụng phương thức xác thực phổ biến nhất là HTTP-01 challenge dành riêng cho tên miền đơn lab-cf02.localhost.vn (không xin chứng chỉ đại diện Wildcard *.domain vốn bắt buộc phải dùng DNS-01). Một bẫy cực kỳ hay gặp: nếu VPS của bạn chưa cấu hình mạng IPv6 hoàn chỉnh, tuyệt đối đừng táy máy tạo bản ghi AAAA trỏ bừa hoặc để sót địa chỉ IPv6 cũ của nhà cung cấp khác — bởi máy chủ xác thực của Let’s Encrypt luôn ưu tiên kết nối qua IPv6 trước, và nếu đi lạc sang máy chủ khác thì quá trình xác minh chắc chắn sẽ thất bại.

Để chắc ăn, từ chiếc máy tính cá nhân ở nhà, bạn hãy mở thử địa chỉ HTTP của trang web xem đã lên đúng nội dung nhận diện chưa; đồng thời trên cửa sổ SSH của VPS, hãy gõ sudo nginx -t để đảm bảo cấu hình hiện tại không có lỗi cú pháp. Hãy tạo thói quen sao lưu file cấu hình Virtual Host ra một thư mục quản trị riêng nằm ngoài web root, kèm theo ghi chú về trạng thái bản ghi DNS và chế độ Proxy hiện tại. Mẹo nhỏ cho những ai dùng Cloudflare: nếu kiến trúc hệ thống cho phép, lúc mới dựng máy chủ bạn hãy tạm để chế độ đám mây xám (DNS Only) để xin và nghiệm thu chứng chỉ TLS gốc tại máy chủ (Origin Server) cho thật gọn gàng, dễ bắt lỗi, rồi sau đó mới bật đám mây cam (Proxy) lên.

Hãy nhớ chỉ thao tác với đúng tên miền thử nghiệm nằm trong phạm vi công việc được giao, tuyệt đối không lấy tên miền đang chạy thật (Production) ra làm chuột bạch hay tiện tay xin thêm các tên miền phụ chưa được phép. Nếu bạn muốn chứng chỉ bao phủ luôn cả nhánh có chữ www đằng trước (ví dụ www.lab-cf02.localhost.vn), bạn bắt buộc phải kiểm tra bản ghi DNS và khai báo server_name cho cả tên miền phụ đó trước; việc tên miền gốc chạy ngon lành không hề đồng nghĩa với việc nhánh www tự động ăn theo.

Sơ đồ các bước chuẩn bị trước khi xin chứng chỉ TLS do đội ngũ localhost.vn biên soạn; đây là tài liệu hướng dẫn trực quan, không phải ảnh chụp màn hình hay bằng chứng chạy lệnh trên lab.

Bước 1: rà soát hiện trạng và cài đặt Certbot từ kho apt của Ubuntu

command -v certbot
apt-cache policy certbot python3-certbot-nginx

Nguyên tắc đầu tiên khi bước vào một chiếc VPS là “nhìn trước ngó sau”: hãy kiểm tra xem trên máy đã có ai cài đặt Certbot từ trước thông qua apt, snap hay các script quản trị hosting (như WordOps, CyberPanel…) hay chưa, đồng thời xem lịch gia hạn tự động đang được quản lý bởi công cụ nào. Tuyệt đối tránh tình trạng cài chồng chéo hai phiên bản Certbot khác nguồn lên cùng một máy chủ khiến chúng tranh chấp cấu hình với nhau. Lệnh apt-cache policy phía trên giúp bạn đọc rõ phiên bản đang cài (Installed), phiên bản ứng viên có sẵn trong kho (Candidate) cũng như nguồn kho chứa gói phần mềm trên hệ thống.

Đối với một chiếc VPS lab cài mới Ubuntu 24.04 LTS sạch sẽ, bài viết này sử dụng trực tiếp gói phần mềm chính thống từ kho apt của Ubuntu — khớp 100% với môi trường thực nghiệm trên máy chủ LAB-CF-02:

sudo apt update &&
  sudo apt install certbot python3-certbot-nginx
/usr/bin/certbot --version

Thành phần kết nối tự động với web server NGINX nằm trong gói mở rộng python3-certbot-nginx. Bạn sẽ thấy trong các bước tiếp theo chúng tôi chủ động viết rõ đường dẫn tuyệt đối /usr/bin/certbot khi gõ lệnh: thói quen cẩn thận này giúp đảm bảo hệ thống luôn gọi đúng bản Certbot cài qua apt mà chúng ta đã kiểm định, tránh mọi nguy cơ gọi nhầm sang đường dẫn /snap/bin/certbot nếu sau này có ai đó cài thêm gói snap. Tất nhiên, nếu bạn đang vận hành một bản phân phối Linux khác hoặc tuân theo quy chuẩn dùng snap của tổ chức, hãy đối chiếu tài liệu tương ứng trước khi thực hiện.

Bước 2: yêu cầu cấp mới và tự động cấu hình chứng chỉ cho đúng tên miền

sudo /usr/bin/certbot --nginx -d lab-cf02.localhost.vn

Khi chạy lệnh trên với tên miền bạn quản lý, Certbot sẽ hiển thị một số câu hỏi tương tác lần đầu: hãy đọc kỹ điều khoản dịch vụ của giao thức ACME (Let’s Encrypt) và nhập một địa chỉ email quản trị thực sự hoạt động để nhận cảnh báo nếu sau này chứng chỉ sắp hết hạn mà gia hạn tự động gặp trục trặc. Hãy chú ý câu hỏi về việc có tự động chuyển hướng (Redirect) toàn bộ lưu lượng HTTP sang HTTPS hay không tùy theo phiên bản Certbot bạn đang chạy. Nhắc lại một lần nữa: bạn chỉ nên nối thêm cờ -d www.ten-mien-cua-ban khi đã xác minh chắc chắn cả DNS lẫn Virtual Host của nhánh www đều đã thông suốt.

Về mặt cơ chế, phương thức HTTP-01 challenge sẽ yêu cầu máy chủ Let’s Encrypt bên ngoài kết nối vào cổng 80 của VPS tại đường dẫn đặc biệt /.well-known/acme-challenge/ để đọc một tập tin xác thực tạm thời. Vì vậy, nếu bạn đang bật khóa mật khẩu tầng web (HTTP Basic Auth), cấu hình tường lửa chặn bot gắt gao hoặc viết các quy tắc chuyển hướng (Redirect) nuốt mất đường dẫn .well-known, quá trình xác minh sẽ báo lỗi ngay lập tức. Khi gặp lỗi, hãy bình tĩnh mở file cấu hình ra sửa đúng nguyên nhân gốc rễ rồi mới chạy lại lệnh; đừng bấm mũi tên lên rồi nhấn Enter liên tục chục lần trong vô vọng, kẻo bạn sẽ chạm trần giới hạn tần suất gọi lỗi (Rate Limit) của Let’s Encrypt và bị khóa mõm tạm thời!

Ngay sau khi Certbot báo chúc mừng đã cấp và gắn chứng chỉ thành công, bạn hãy mở lại file cấu hình Virtual Host của NGINX để đọc hiểu những dòng chỉ thị ssl_certificate mà plugin vừa tự động chèn vào. Hãy bảo vệ nghiêm ngặt tập tin khóa bí mật (privkey.pem) bên trong thư mục /etc/letsencrypt/, tuyệt đối không copy ra nơi công cộng hay mở quyền đọc bừa bãi, rồi chạy cặp lệnh đối chiếu sau:

sudo nginx -t
sudo /usr/bin/certbot certificates

Hãy ghi chép lại chính xác danh sách các tên miền được bao phủ (Subject Alternative Name – SAN) cùng ngày giờ hết hạn thực tế của chứng chỉ vừa nhận vào sổ tay vận hành. Đừng bao giờ mặc định trong đầu một con số ngày cố định cho mọi loại chứng chỉ trên đời, bởi các tổ chức cấp phát (CA) và tiêu chuẩn ngành hoàn toàn có thể rút ngắn vòng đời chứng chỉ theo thời gian. Điều quan trọng nhất là bạn phải có cơ chế gia hạn tự động chạy ngầm ổn định kết hợp với công cụ giám sát hạn sử dụng từ bên ngoài để có người kịp thời xử lý nếu xảy ra sự cố.

Bước 3: nghiệm thu kết nối HTTPS từ mạng bên ngoài

curl -I https://lab-cf02.localhost.vn/
curl -I http://lab-cf02.localhost.vn/

Khi dùng curl từ máy tính cá nhân để kiểm tra kết nối HTTPS, bạn hãy để công cụ thực hiện xác thực chuỗi chứng chỉ TLS một cách nghiêm ngặt theo mặc định — tuyệt đối không thêm cờ -k (hoặc --insecure) để bỏ qua lỗi chứng chỉ! Song song đó, hãy mở trình duyệt web truy cập vào trang, bấm vào biểu tượng thông tin bảo mật cạnh thanh địa chỉ để tận mắt đọc tên miền được cấp trong chứng chỉ (Common Name / SAN) cùng ngày hết hạn. Lưu ý nhỏ cho những ai hay đọc tài liệu cũ: các trình duyệt hiện đại ngày nay (như Chrome) đã thay đổi biểu tượng ổ khóa màu xanh truyền thống thành biểu tượng cài đặt trang (Tune icon), nên bạn hãy bấm vào mục Connection is secure / Certificate is valid để xem chi tiết thay vì ngồi tìm hình chiếc ổ khóa như ảnh chụp từ chục năm trước.

Nếu bạn đã chọn bật tính năng tự động chuyển hướng từ HTTP sang HTTPS, hãy nhìn kỹ dòng Location: trong kết quả curl -I http://... để chắc chắn nó trả về mã 301 Moved Permanently trỏ thẳng sang đúng địa chỉ https:// của tên miền chính. Còn trong trường hợp bạn chủ ý giữ lại cổng HTTP tạm thời để phục vụ bài thực hành chuyển đổi chuyên sâu ở bài 45, hãy nhớ quy tắc sắt đá: tuyệt đối không gõ mật khẩu đăng nhập qua đường HTTP đó. Chỉ mở xem trang HTML nhận diện bên ngoài, rồi chuyển sang đường dẫn HTTPS chuẩn để tiếp tục cấu hình WordPress.

Sơ đồ các tiêu chí nghiệm thu sau khi cấp chứng chỉ TLS do localhost.vn biên soạn; đây là hình vẽ hệ thống hóa kiến thức, không phải ảnh chụp màn hình hay kết quả chạy lệnh trên lab.

Bước 4: diễn tập gia hạn tự động (Dry-run) và kiểm tra bộ lập lịch systemd timer

sudo /usr/bin/certbot renew --dry-run
systemctl is-enabled certbot.timer
systemctl is-active certbot.timer
systemctl list-timers --all certbot.timer
systemctl status certbot.service --no-pager

Chứng chỉ của Let’s Encrypt có thời hạn ngắn (thường là 90 ngày), nên nếu bạn chỉ xin cấp mới một lần rồi quên bẵng đi thì đúng 3 tháng sau khách hàng sẽ gọi điện mắng vốn vì trang web hiện cảnh báo đỏ lòm. Lệnh certbot renew --dry-run ở trên sẽ giả lập toàn bộ quy trình gia hạn chứng chỉ thông qua máy chủ thử nghiệm (Staging environment) của Let’s Encrypt mà không làm ảnh hưởng tới chứng chỉ thật đang chạy. Tất nhiên, một lần chạy dry-run thành công hôm nay chứng minh đường ống cấu hình hiện tại đang thông suốt, chứ không phải giấy bảo hành vĩnh viễn rằng các tháng sau sẽ không bao giờ lỗi (nếu sau này có ai đó sửa tường lửa hoặc đổi DNS). Vì vậy, hãy kiểm tra kỹ trạng thái của bộ lập lịch systemd timer đi kèm gói cài đặt và biết cách đọc log khi cần.

Một điểm khiến rất nhiều anh em mới làm quen với systemd bị giật mình thon thót: khi bạn gõ lệnh xem trạng thái của certbot.service, bạn sẽ thấy nó hiện chữ inactive (dead)! Đừng hoảng hốt tưởng dịch vụ bị chết: bởi vì certbot.service thuộc loại tiến trình chạy một lần rồi nghỉ (Type=oneshot) được kích hoạt định kỳ bởi certbot.timer, nên sau khi thức dậy kiểm tra hạn chứng chỉ vài giây xong xuôi, nó sẽ tự động đóng lại và trở về trạng thái inactive (dead). Để biết lần chạy gần nhất có êm đẹp hay không, hãy nhìn vào mã thoát (exit code), thời điểm hoàn tất và đọc nhật ký hệ thống bằng lệnh sudo journalctl -u certbot.service -n 50 --no-pager. Theo đúng tài liệu chính thức về cơ chế gia hạn của Certbot, mã thoát 0 (status=0/SUCCESS) có nghĩa là tiến trình chạy kiểm tra đã hoàn tất không lỗi — bao gồm cả trường hợp đã gia hạn thành công lẫn trường hợp kiểm tra thấy chứng chỉ còn hạn dài nên giữ nguyên chưa cần cấp mới. Do đó, muốn biết thực sự chứng chỉ đã được đổi mới hay chưa, bạn cần xem thêm ngày hết hạn của chứng chỉ.

Trong suốt vòng đời vận hành website sau này, bạn phải luôn giữ cho con đường xác thực challenge được thông thoáng. Bất cứ khi nào bạn thay đổi quy tắc tường lửa cổng 80, bật tắt dịch vụ Proxy trung gian hoặc gắn thêm lớp mật khẩu bảo vệ trang web, hãy nhớ chạy lại lệnh --dry-run ngay lập tức để chắc chắn đường gia hạn không bị vô tình chặn mất. Song song đó, hãy thiết lập một công cụ giám sát hạn chứng chỉ SSL từ bên ngoài (Uptime / SSL Expiry Monitor) và phân công rõ người nhận cảnh báo để chủ động xử lý trước ngày hết hạn.

Mẹo nhỏ tránh tự bắn vào chân: khi gói apt của Ubuntu đã tự động tạo sẵn certbot.timer chuẩn chỉnh rồi, bạn đừng tự tay viết thêm một dòng lệnh crontab thứ hai để gọi gia hạn nữa! Việc tồn tại hai lịch chạy song song vừa làm rối loạn nhật ký theo dõi, vừa chẳng giải quyết được gì nếu nguyên nhân lỗi nằm ở cấu hình mạng.

Góc mở rộng: lưu ý sống còn nếu website của bạn đứng sau Cloudflare Proxy

Khi bạn bật biểu tượng đám mây màu cam (Proxy) trên bảng điều khiển Cloudflare, luồng kết nối thực tế bị tách làm hai chặng độc lập: chặng thứ nhất từ trình duyệt của người đọc tới máy chủ biên (Edge) của Cloudflare, và chặng thứ hai từ Cloudflare kết nối về máy chủ VPS gốc (Origin) của bạn. Chế độ bảo mật chuẩn mực duy nhất bạn nên chọn là Full (strict) — chế độ này yêu cầu trên VPS gốc bắt buộc phải có một chứng chỉ TLS hợp lệ (do CA công cộng như Let’s Encrypt cấp hoặc dùng Cloudflare Origin CA). Tuyệt đối đừng vì lười cài chứng chỉ trên VPS mà chọn bừa chế độ Flexible: nó không chỉ để hở toàn bộ dữ liệu chạy không mã hóa trên chặng đường từ Cloudflare về VPS, mà còn là thủ phạm số một gây ra căn bệnh kinh niên “vòng lặp chuyển hướng vô tận” (ERR_TOO_MANY_REDIRECTS) trên WordPress!

Hãy nhớ rằng một khi đám mây cam đã bật, chứng chỉ mà bạn nhìn thấy trên trình duyệt web thực chất là chứng chỉ đại diện ở tầng Edge của Cloudflare chứ không phải chứng chỉ nằm trong NGINX trên VPS của bạn. Vì vậy, khi ghi biên bản nghiệm thu, hãy luôn phân biệt rõ bạn đang kiểm tra chứng chỉ ở chặng nào. Ngoài ra, chứng chỉ miễn phí mặc định ở tầng Edge của Cloudflare (Universal SSL) chỉ bao phủ tên miền gốc và các subdomain cấp một (*.domain.com); nếu bạn dùng các tên miền phụ nhiều cấp sâu hơn (như a.b.domain.com), hãy kiểm tra kỹ phạm vi bao phủ trước khi bật Proxy.

Sơ đồ nguyên tắc duy trì gia hạn chứng chỉ tự động do localhost.vn biên soạn; đây là hình vẽ hệ thống hóa quy trình, không phải ảnh chụp màn hình hay kết quả chạy lệnh trên lab.

Chẩn đoán lỗi nhanh, phương án khôi phục (Rollback) và FAQ

Lỗi Timeout during connect (likely firewall problem): Hãy rà soát ngay bản ghi DNS A/AAAA xem đã trỏ đúng IP chưa, tường lửa (UFW / Security Group của nhà cung cấp VPS) đã mở cổng TCP 80 chưa, và thử truy cập đường dẫn challenge từ một mạng bên ngoài. Lỗi Unauthorized (Invalid response): Kiểm tra xem tên miền có đang đi nhầm vào một block Virtual Host mặc định khác trên cùng VPS không, hoặc thư mục .well-known/acme-challenge/ có đang bị quy tắc chặn file ẩn (location ~ /\.) trong NGINX hay bộ nhớ đệm làm biến dạng nội dung phản hồi hay không. Lỗi chứng chỉ báo sai tên miền (SSL_ERROR_BAD_CERT_DOMAIN): Đối chiếu lại chính xác tên miền trên thanh địa chỉ, cấu hình SNI và danh sách tên miền đã khai báo trong chứng chỉ.

Trong trường hợp plugin tự động của Certbot sửa file cấu hình NGINX theo cách không tương thích với thiết kế tùy biến của bạn, bạn chỉ cần copy đè lại bản sao lưu file Virtual Host đã cất giữ trước lúc chạy, gõ sudo nginx -t kiểm tra cú pháp rồi reload lại dịch vụ. Nếu vì lý do bất khả kháng phải tạm thời lùi về chạy HTTP trong lúc sửa lỗi cấu hình, hãy treo một trang HTML thông báo bảo trì tĩnh và khóa cổng đăng nhập quản trị cho tới khi khắc phục xong TLS — tuyệt đối không để quản trị viên nhập mật khẩu qua kết nối không mã hóa. Một lưu ý cực kỳ quan trọng khi dọn dẹp: đừng bao giờ xóa tay các thư mục chứng chỉ trong /etc/letsencrypt/ khi file cấu hình NGINX vẫn đang có dòng ssl_certificate trỏ tới chúng, nếu không dịch vụ NGINX sẽ lập tức từ chối khởi động ở lần reload tiếp theo!

Tôi có thể xin chứng chỉ Let’s Encrypt trực tiếp cho địa chỉ IP của VPS mà không cần mua tên miền được không? Bài hướng dẫn này làm việc hoàn toàn trên tên miền chuẩn và không áp dụng cho địa chỉ IP trần. Đặc biệt với hệ sinh thái WordPress (vốn lưu cứng đường dẫn gốc trong cơ sở dữ liệu và xử lý Cookie theo domain), việc sử dụng một tên miền hoặc subdomain đàng hoàng ngay từ đầu sẽ giúp bạn tránh được vô số rắc rối vận hành về sau.

Sau khi đã bật HTTPS thành công mỹ mãn rồi thì tôi đóng luôn cổng 80 trên tường lửa cho gọn được không? Không nên chút nào nếu bạn vẫn đang dùng phương thức HTTP-01 challenge! Bởi đến kỳ gia hạn tự động sau 60 ngày, máy chủ Let’s Encrypt vẫn sẽ gõ cửa cổng 80 để xác minh lại quyền sở hữu tên miền; đồng thời người dùng gõ tên miền trên trình duyệt thường không gõ chữ https:// nên vẫn cần cổng 80 mở để nhận lệnh Redirect 301 sang cổng 443. Nếu vì quy định bảo mật đặc thù bắt buộc phải đóng kín cổng 80, bạn phải chuyển sang phương thức xác thực qua API DNS (DNS-01 challenge) và thử nghiệm kỹ quy trình gia hạn mới đó.

Khi nào thì tôi có thể đánh dấu hoàn tất bước cài đặt TLS này? Khi và chỉ khi: kết nối HTTPS hoạt động chuẩn xác với đúng tên miền, cổng HTTP chuyển hướng đúng như thiết kế, lệnh --dry-run báo thành công, bộ lập lịch certbot.timer đang chạy thực tế và bạn đã lưu giữ đầy đủ log/ảnh chụp vào biên bản. Trên máy chủ thử nghiệm LAB-CF-02 của chúng ta, toàn bộ log cấp chứng chỉ, kết quả kiểm tra HTTPS, kết quả dry-run cùng ảnh chụp màn hình console xác nhận tiến trình chạy tự động theo timer đều đã có đủ. Tất nhiên, do chứng chỉ vừa mới cấp còn hạn rất dài nên lần chạy định kỳ của timer mới chỉ kiểm tra hạn rồi đóng lại chứ chưa thực sự xin cấp chứng chỉ mới — vì vậy việc theo dõi định kỳ khi đến kỳ gia hạn thật sự vẫn là một phần không thể thiếu trong vận hành.

Báo cáo thực nghiệm cấp chứng chỉ TLS trên LAB-CF-02 (30/09/2026)

Theo nhật ký vận hành ngày 30/09/2026, công cụ Certbot đã hoàn tất việc xin cấp mới và tự động gắn chứng chỉ TLS vào NGINX cho tên miền lab-cf02.localhost.vn. Bảng dưới đây tổng hợp các thông số kỹ thuật đo kiểm lúc 22:48 (UTC+7) cùng ngày:

Ngay trong tối ngày 30/09/2026, nhật ký chạy thử nghiệm gia hạn đã ghi nhận dòng thông báo all simulated renewals succeeded (mọi phép thử gia hạn giả lập đều thành công) đối với chứng chỉ này. Lưu ý đây là kết quả từ lệnh --dry-run gõ thủ công; tại thời điểm 22:48 tối hôm đó, bộ lập lịch tự động certbot.timer chưa đến giờ kích hoạt lần đầu tiên. Bức ảnh chụp màn hình vào sáng ngày 01/10 ở mục ngay bên dưới sẽ bổ sung bằng chứng cho thấy dịch vụ đã tự động thức dậy chạy theo lịch hẹn thành công (dù chưa phải là cấp chứng chỉ mới do chưa đến kỳ gia hạn). Cũng vào lúc 22:51 (UTC+7) ngày 30/09, lệnh curl gọi từ một máy tính bên ngoài VPS đã nhận về mã chuyển hướng HTTP 301 sang HTTPS và nhận tiếp mã HTTPS 200 với xác thực TLS chuẩn chỉnh (hoàn toàn không dùng cờ -k).

Kết quả truy vấn từ apt-cache policy khẳng định máy chủ lab đang vận hành gói ổn định 2.9.0-1 của bản phân phối Ubuntu 24.04 (chúng ta gọi đúng bản chất là gói chuẩn của distro chứ không gọi bừa là phiên bản Certbot mới nhất trên thế giới). Trong phạm vi bài thực hành cơ bản này, chúng tôi giữ môi trường gọn gàng, không cài nhánh snap, không dùng tên miền phụ www, không bật lớp Cloudflare Proxy và không cần phải kích hoạt quy trình rollback cấu hình.

Bằng chứng đối chiếu hoạt động của systemd timer và chứng chỉ ngày 01/10/2026

Sáng ngày hôm sau, cửa sổ giao diện Console trên hạ tầng CloudFly của máy chủ localhost-tutorial-lab-02 ghi nhận mốc kiểm tra lúc 09:10:02 ngày 01/10/2026 (UTC+7). Bảng tóm tắt dưới đây phản ánh trạng thái hệ thống tự vận hành qua đêm mà không có bất kỳ lệnh xin cấp mới hay ép gia hạn thủ công nào:

Ảnh chụp giao diện Console thực tế tại mốc 09:10:02 sáng ngày 01/10/2026 (UTC+7); giữ nguyên độ phân giải pixel vùng chụp và gắn thêm logo ở chân ảnh. Bấm vào ảnh để xem kích thước đầy đủ. Bức ảnh xác nhận dịch vụ certbot.service đã được certbot.timer đánh thức tự động vào lúc 06:26 sáng và kết thúc thành công không lỗi (0/SUCCESS); tất nhiên vì chứng chỉ mới cấp tối hôm trước còn nguyên gần 90 ngày hiệu lực nên Certbot chỉ kiểm tra rồi giữ nguyên chứ chưa xin cấp chứng chỉ mới. Dòng thông tin Private Key trên màn hình chỉ in đường dẫn tập tin trên ổ cứng, hoàn toàn không làm lộ nội dung khóa bí mật.

Đợt quan sát sáng ngày 01/10 này hoàn toàn mang tính chất đọc trạng thái tự nhiên của hệ thống, không chạy lại lệnh --dry-run hay ép gia hạn cưỡng bức. Ngày hết hạn của chứng chỉ vẫn giữ nguyên như tối ngày 30/09. Trong thực tế vận hành lâu dài, bạn vẫn cần duy trì hệ thống giám sát hạn chứng chỉ khi bước vào cửa sổ 30 ngày cuối trước khi hết hạn, bởi một lần chạy kiểm tra 0/SUCCESS hôm nay chưa thể thay thế cho việc xác nhận chứng chỉ mới được ghi xuống ổ cứng vào hai tháng sau.

Tài liệu tham khảo và hành trình tiếp theo

Tài liệu chính thức tại mục Certbot Documentation: Renewing certificates đã được chúng tôi tra cứu và đối chiếu lại vào ngày 01/10/2026, đặc biệt để làm rõ ý nghĩa của mã thoát 0 khi tiến trình kiểm tra định kỳ thấy chứng chỉ chưa đến hạn cần đổi mới. Các tài liệu kỹ thuật nền tảng giữ mốc đối chiếu ngày 30/09/2026 bao gồm: Let’s Encrypt Documentation: Challenge Types (HTTP-01 & DNS-01) và Cloudflare SSL/TLS Documentation: Full (strict) encryption mode. Toàn bộ sơ đồ quy trình và kịch bản xử lý sự cố trong bài được biên soạn riêng cho chuỗi bài thực hành này.

Mời bạn xem lại bức tranh tổng thể tại lộ trình cài đặt và vận hành WordPress trên VPS từ A đến Z. Bài trước: Nghiệm thu WordPress sau cài đặt — Bài viết, Media Library, Permalink và Login. Bài tiếp theo: Đưa WordPress ra mắt công chúng (Go-live Checklist) — rà soát HTTPS, nội dung, biểu mẫu và lập chỉ mục tìm kiếm.