Câu trả lời ngắn: Với website đang chạy Nginx trên Ubuntu, cách phổ biến để bật HTTPS là dùng Certbot với Nginx plugin. Trước khi chạy lệnh, domain phải trỏ đúng về máy chủ, website HTTP phải truy cập được qua port 80 và cấu hình Nginx phải vượt qua nginx -t. Sau khi cấp chứng chỉ, cần kiểm tra redirect HTTPS, cấu hình renewal và chạy thử certbot renew --dry-run thay vì chờ đến lúc certificate hết hạn.
Let’s Encrypt cấp certificate Domain Validation miễn phí, nhưng miễn phí không có nghĩa là có thể cài một lần rồi quên. Certificate mặc định có thời hạn 90 ngày, private key nằm trên máy chủ của bạn và quy trình renew phải được kiểm tra định kỳ. Bài viết này trình bày quy trình thực tế cho Nginx, bao gồm kiểm tra DNS, cài Certbot, phát hành certificate, redirect HTTPS, xác minh tự động gia hạn và rollback khi cấu hình mới gây lỗi.
1. Khi nào nên dùng Certbot với Nginx?
Certbot phù hợp khi bạn có quyền quản trị máy chủ và muốn tự động thực hiện hai việc: xác thực quyền kiểm soát domain để lấy certificate, sau đó cài certificate vào Nginx. Nginx plugin có thể đóng vai trò vừa là authenticator vừa là installer. Trường hợp chỉ muốn lấy file certificate mà không cho Certbot tự sửa cấu hình, hãy dùng certbot certonly và tự cấu hình Nginx.
Quy trình dưới đây phù hợp với domain chính, subdomain và nhiều virtual host trên một VPS. Nếu bạn dùng shared hosting cPanel không có quyền root hoặc không quản lý được Nginx, hãy dùng công cụ SSL của nhà cung cấp thay vì cố chạy Certbot trên tài khoản hosting. Với wildcard như *.example.com, cần dùng DNS-01 challenge; HTTP-01 không cấp wildcard certificate.
2. Checklist trước khi cài SSL
- Domain và các bản ghi A/AAAA trỏ đến đúng máy chủ.
- Website HTTP đã phản hồi đúng qua port 80 từ Internet.
- Port 80 và 443 được mở trên firewall, security group và nhà cung cấp hosting.
- Virtual host Nginx có
server_nameđúng domain. - Đã backup thư mục cấu hình Nginx trước khi để Certbot chỉnh sửa.
- Lệnh
sudo nginx -ttrả về thông báo cấu hình hợp lệ.
Kiểm tra DNS và HTTP trước khi cài:
dig +short example.com A
dig +short www.example.com A
curl -I http://example.com
sudo nginx -t
sudo ss -lntp | grep -E ':80|:443'Nếu curl -I http://example.com trả về 301 sang một domain khác, trả 404 do sai virtual host hoặc không kết nối được, hãy sửa nguyên nhân đó trước. ACME server cần truy cập được domain trong quá trình challenge; Certbot không thể bù cho DNS sai hoặc port bị chặn.
3. Backup cấu hình Nginx trước khi thay đổi
Certbot có thể tự thêm các directive SSL và redirect vào server block. Hãy lưu bản sao có timestamp để rollback có điểm quay lại rõ ràng:
sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%Y%m%d-%H%M%S)
sudo nginx -T > ~/nginx-config-before-certbot.txt
sudo nginx -tKhông nên chỉ backup một file trong sites-available nếu hệ thống còn include từ conf.d, snippet hoặc file symlink trong sites-enabled. Lệnh nginx -T giúp ghi lại cấu hình sau khi Nginx đã mở rộng các dòng include.
4. Cài Certbot và Nginx plugin trên Ubuntu
Phương thức cài đặt phụ thuộc vào phiên bản Ubuntu và chính sách của hệ thống. Hãy ưu tiên hướng dẫn chính thức của Certbot cho hệ điều hành đang dùng. Trên nhiều bản Ubuntu hiện nay, Certbot được phân phối qua Snap:
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot --versionNếu máy chủ đã có Certbot từ package manager, không nên cài chồng nhiều bản mà chưa kiểm tra đường dẫn:
command -v certbot
certbot --version
sudo systemctl list-timers | grep -i certbot || true
sudo snap services certbot 2>/dev/null || true5. Cấp và cài certificate bằng Nginx plugin
Với domain chính và phiên bản www, có thể dùng:
sudo certbot --nginx -d example.com -d www.example.comCertbot sẽ yêu cầu email, điều khoản dịch vụ và lựa chọn redirect HTTP sang HTTPS. Ở website production, nên chọn redirect sau khi xác nhận tất cả host cần thiết đều đã nằm trong certificate. Nếu domain còn một subdomain chưa trỏ về server này, bỏ nó khỏi lệnh hoặc sửa DNS trước; không nên ép cấp certificate cho hostname chưa sẵn sàng.
Nếu muốn tách việc cấp certificate khỏi việc cài vào Nginx:
sudo certbot certonly --nginx -d example.com -d www.example.com
sudo ls -la /etc/letsencrypt/live/example.com/Certificate thường được cung cấp qua symlink trong /etc/letsencrypt/live/<domain>/. Không nên copy private key ra thư mục public hoặc đưa vào Git. Quyền đọc private key phải chỉ dành cho các tiến trình cần dùng.
6. Kiểm tra cấu hình HTTPS sau khi Certbot hoàn tất
Đừng coi màn hình “Congratulations” là bước kiểm tra cuối. Hãy kiểm tra syntax, reload và các header:
sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com
curl -I https://example.com
curl -sS https://example.com | headHTTP nên redirect đến HTTPS theo đúng host và path mong muốn. HTTPS phải trả nội dung đúng website, không phải default server. Kiểm tra thêm certificate:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltNameĐể kiểm tra nhanh bằng công cụ bên ngoài, có thể dùng SSL Labs hoặc một máy khác trong mạng. Hãy kiểm tra cả domain không www, www và các API/subdomain nếu chúng nằm trong cùng quy trình triển khai.
7. Renewal tự động: kiểm tra chứ không phỏng đoán
Certbot thường cài timer hoặc cơ chế scheduled task để chạy renewal. Lệnh kiểm tra an toàn nhất là:
sudo certbot renew --dry-runDry run giúp kiểm tra quy trình renew mà không thay certificate production. Nếu dry run thất bại, đọc nguyên nhân trong output và log trước khi sửa. Một số nguyên nhân thường gặp là DNS đã đổi, port 80 bị firewall chặn, challenge path bị rewrite, virtual host bắt sai domain hoặc rate limit.
systemctl list-timers --all | grep -i certbot
sudo journalctl -u snap.certbot.renew.service --since '7 days ago'
sudo tail -n 100 /var/log/letsencrypt/letsencrypt.logLet’s Encrypt khuyến nghị ACME client chạy renewal ở thời điểm ngẫu nhiên để tránh nhiều máy cùng tạo tải tại đúng một thời điểm. Không cần tự tạo cron chạy mỗi phút; hãy dùng timer được package hỗ trợ và kiểm tra trạng thái của timer đó.
8. Cấu hình redirect HTTPS và các lỗi cần tránh
Redirect HTTP sang HTTPS là lựa chọn phổ biến cho website public:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Không nên redirect tất cả domain trong một default server nếu máy chủ đang phục vụ nhiều website. Mỗi domain cần server block và certificate phù hợp. Với reverse proxy, hãy kiểm tra thêm X-Forwarded-Proto và cấu hình ứng dụng để không tạo vòng lặp redirect.
9. Rollback khi Certbot làm Nginx không khởi động
Nếu nginx -t báo lỗi sau khi chạy Certbot, chưa nên restart liên tục. Trước tiên đọc dòng lỗi và xác định file:
sudo nginx -t
sudo nginx -T | less
sudo journalctl -u nginx -n 100 --no-pagerNếu cần quay lại bản backup, chỉ thực hiện sau khi xác định đường dẫn backup và có kế hoạch bảo toàn certificate đã cấp:
sudo mv /etc/nginx /etc/nginx.failed.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/nginx.backup.YYYYMMDD-HHMMSS /etc/nginx
sudo nginx -t
sudo systemctl reload nginxRollback cấu hình Nginx không đồng nghĩa với xóa certificate trong /etc/letsencrypt. Hãy tách hai việc này để tránh xóa nhầm dữ liệu renewal. Chỉ dùng certbot delete khi bạn hiểu certificate nào không còn được sử dụng.
10. Checklist production sau khi bật HTTPS
- HTTP redirect đúng sang HTTPS và không tạo vòng lặp.
- HTTPS trả đúng nội dung, đúng host và đúng canonical.
- Certificate chứa đủ domain và ngày hết hạn hợp lệ.
nginx -tpass sau mỗi thay đổi.certbot renew --dry-runpass.- Timer/service renewal hoạt động.
- Log Let’s Encrypt và log Nginx được theo dõi.
- Đã lưu backup và biết cách rollback.
Kết luận
Cài SSL Let’s Encrypt cho Nginx không chỉ là chạy một lệnh Certbot. Quy trình production đúng phải bắt đầu từ DNS và port 80, backup cấu hình, kiểm tra Nginx, cài certificate, xác minh redirect/chain, test renewal và chuẩn bị rollback. Nếu website chạy sau reverse proxy hoặc có nhiều virtual host, hãy kiểm tra từng host thay vì áp dụng redirect và certificate một cách hàng loạt.
Bạn có thể xem thêm bài cấu hình Nginx reverse proxy cho nhiều website trên cùng VPS để hoàn thiện phần routing trước khi bật HTTPS. Bài về cache static file cũng sẽ giúp tối ưu asset sau khi giao thức HTTPS đã ổn định.