SSL hết hạn hoặc lỗi chuỗi chứng chỉ: cách khoanh vùng và xử lý

Cảnh báo "Kết nối không an toàn" trên trình duyệt xuất hiện khi quá trình bắt tay TLS giữa người dùng và máy chủ bị lỗi. Tuy nhiên, trong các mô hình triển khai có sử dụng Cloudflare, Load Balancer hay cụm máy chủ phân tán, điểm phát sinh lỗi chưa chắc đã nằm ở tệp chứng chỉ trên VPS.

Một chứng chỉ mới có thể đã được Certbot gia hạn về đĩa cứng nhưng Nginx chưa reload để nạp vào RAM. Hoặc chứng chỉ trên máy chủ gốc vẫn còn hạn nhưng Cloudflare ở tầng ngoài chưa kích hoạt SSL cho tên miền phụ mới tạo. Can thiệp vội vã vào web server khi chưa xác định đúng tầng lỗi sẽ chỉ làm mất thời gian mà không giải quyết được vấn đề.

Quy trình khoanh vùng chuẩn xác là: kiểm tra trực tiếp quá trình bắt tay TLS từ môi trường mạng bên ngoài, đọc đúng chứng chỉ và chuỗi trung gian (intermediate chain), phân định rõ giữa tầng CDN biên và máy chủ gốc, rồi mới tiến hành cập nhật cấu hình hoặc gia hạn.

Bảng phân loại nhanh các lỗi SSL/TLS phổ biến

Bước 1: Kiểm tra chứng chỉ thực tế trả về từ bên ngoài

Thay vì đoán mò trên máy chủ, hãy đứng từ môi trường mạng bên ngoài và dùng công cụ dòng lệnh openssl để kiểm tra kết nối bắt tay TLS thực tế:

openssl s_client -connect tenmien.com:443 -servername tenmien.com -showcerts </dev/null

Tham số -servername tenmien.com là bắt buộc vì nó gửi thông tin SNI (Server Name Indication). Nếu thiếu tham số này, web server sẽ trả về chứng chỉ mặc định của máy chủ và khiến bạn chẩn đoán sai lệch.

Đọc kỹ các thông tin cốt lõi trong kết quả trả về:

• subject và SAN (Subject Alternative Name): Danh sách các tên miền được chứng chỉ này bảo vệ.
• issuer: Đơn vị cấp chứng chỉ (Let's Encrypt, Cloudflare, DigiCert).
• notBefore và notAfter: Khoảng thời gian chứng chỉ có hiệu lực.
• Verify return code: Mã xác thực chuỗi chứng chỉ (mã 0 (ok) biểu thị chuỗi tin cậy hoàn hảo).

Bạn cũng có thể kiểm tra nhanh bằng lệnh:

curl -Iv https://tenmien.com

Lưu ý: Không dùng cờ -k (insecure) khi kiểm tra, vì cờ này bỏ qua việc xác thực chứng chỉ — điều mà trình duyệt của người dùng thực tế bắt buộc phải làm.

Bước 2: Kiểm tra tên miền (SAN) và ngày hết hạn

Hai lỗi cơ bản nhất của chứng chỉ máy chủ (Leaf Certificate):

1. Tên miền không khớp (Name Mismatch)

Chứng chỉ cấp cho tenmien.com không tự động bảo vệ cho các subdomain như api.tenmien.com hay staging.tenmien.com, trừ khi bạn đăng ký chứng chỉ dạng Wildcard (*.tenmien.com).

Nếu tên miền đã có trong SAN nhưng trình duyệt vẫn báo lỗi, hãy kiểm tra:

• Khối server_name trong Nginx có khai báo đúng tên miền hay đang rơi vào cấu hình mặc định (default virtual host).
• Bản ghi DNS IPv6 (bản ghi AAAA) có đang trỏ sang một máy chủ cũ chưa cập nhật chứng chỉ mới hay không.

2. Chứng chỉ thực sự đã hết hạn

So sánh trường notAfter với thời gian UTC hiện tại. Nếu chứng chỉ đã quá hạn, bạn cần kiểm tra xem tiến trình tự động gia hạn (như Certbot timer hoặc acme.sh) vì sao lại thất bại ở các bước tiếp theo.

Bước 3: Lỗi thiếu chứng chỉ trung gian (Incomplete Certificate Chain)

Đây là lỗi rất phổ biến khiến website mở được trên một số máy tính (do trình duyệt đã lưu cache sẵn chứng chỉ trung gian từ trước) nhưng lại báo lỗi "Không thể xác minh nhà phát hành" trên điện thoại di động hoặc các API client (như cURL, ứng dụng di động).

Mô hình chuỗi tin cậy tiêu chuẩn gồm 3 cấp:

1. Root CA: Chứng chỉ gốc được cài sẵn trong hệ điều hành của người dùng.
2. Intermediate CA: Chứng chỉ trung gian do Root CA cấp quyền.
3. Leaf Certificate: Chứng chỉ trang web của bạn do Intermediate CA cấp.

Trình duyệt của người dùng chỉ có sẵn Root CA. Do đó, máy chủ web của bạn bắt buộc phải gửi kèm chứng chỉ trung gian trong quá trình bắt tay TLS để người dùng có thể xây dựng cầu nối tin cậy từ trang web của bạn lên Root CA.

Cách xử lý đúng trên Nginx:

Trong tệp cấu hình Nginx, tại chỉ thị ssl_certificate, bạn phải trỏ tới tệp fullchain.pem, không được trỏ tới tệp cert.pem:

# Cấu hình CHUẨN: chứa cả leaf cert và intermediate cert
ssl_certificate /etc/letsencrypt/live/tenmien.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tenmien.com/privkey.pem;

# Cấu hình SAI (thiếu chuỗi trung gian):
# ssl_certificate /etc/letsencrypt/live/tenmien.com/cert.pem;

Tệp fullchain.pem được tạo theo thứ tự chuẩn: chứng chỉ của bạn nằm ở đầu tệp, tiếp theo ngay bên dưới là chứng chỉ của Intermediate CA.

Bước 4: Tách biệt chứng chỉ ở tầng CDN và tầng Máy chủ gốc (Origin)

Nếu website của bạn nằm sau Cloudflare hoặc các hệ thống CDN, thực tế có tới 2 đường truyền mã hóa TLS độc lập:

Trình duyệt người dùng ── (TLS 1) ──> Cloudflare Edge ── (TLS 2) ──> Nginx trên VPS

Bạn cần xác định lỗi đang xuất hiện ở chặng nào:

Trường hợp 1: Trình duyệt báo lỗi SSL trước khi tới Cloudflare

Lỗi nằm ở chứng chỉ của Cloudflare Edge (Edge Certificate). Hãy đăng nhập vào Cloudflare Dashboard, vào mục SSL/TLS → Edge Certificates để kiểm tra trạng thái chứng chỉ đã được kích hoạt (Active) cho tên miền của bạn hay chưa. Việc chỉnh sửa chứng chỉ trên VPS trong trường hợp này hoàn toàn không có tác dụng.

Trường hợp 2: Màn hình xuất hiện Cloudflare Error 526

Mã lỗi Error 526: Invalid SSL Certificate xuất hiện khi bạn cấu hình chế độ mã hóa Full (strict) trên Cloudflare, nhưng chứng chỉ cài đặt trên máy chủ VPS của bạn gặp một trong các vấn đề:

• Chứng chỉ trên VPS đã hết hạn.
• Tên miền trên chứng chỉ VPS không khớp với tên miền đang kết nối.
• Sử dụng chứng chỉ tự ký (Self-signed) không hợp lệ.

Để giải quyết Error 526:

• Tự gia hạn chứng chỉ Let's Encrypt hợp lệ trên VPS cho đúng tên miền đó.
• Hoặc tạo một chứng chỉ Cloudflare Origin CA miễn phí (thời hạn lên tới 15 năm) từ trang quản trị Cloudflare và cài đặt trực tiếp vào Nginx của VPS. Đây là giải pháp ổn định nhất cho các hệ thống nằm sau Cloudflare.
• Tránh hạ cấp chế độ mã hóa xuống "Flexible" chỉ để chữa cháy tạm thời, vì chế độ này sẽ truyền dữ liệu từ Cloudflare về VPS dưới dạng văn bản thuần không mã hóa qua cổng 80.

Bước 5: Chứng chỉ trên đĩa cứng đã mới nhưng Nginx vẫn phát chứng chỉ cũ

Một sự cố rất thường gặp: bạn kiểm tra thư mục /etc/letsencrypt/live/tenmien.com/ thấy tệp fullchain.pem đã được gia hạn thành công sang thời hạn của 3 tháng tới, nhưng khi truy cập web bằng openssl từ bên ngoài, hệ thống vẫn trả về chứng chỉ cũ đã hết hạn.

Nguyên nhân là do Nginx chỉ đọc tệp tin chứng chỉ vào bộ nhớ RAM tại thời điểm khởi động. Nếu sau khi Certbot gia hạn xong mà bạn không thực hiện reload Nginx, dịch vụ web sẽ tiếp tục phục vụ chứng chỉ cũ từ bộ nhớ RAM.

Quy trình xử lý chuẩn:

1. Kiểm tra cú pháp cấu hình Nginx: sudo nginx -t
2. Làm mới cấu hình Nginx mà không gián đoạn kết nối: sudo systemctl reload nginx
3. Kiểm tra lại chứng chỉ từ bên ngoài bằng openssl s_client để xác nhận ngày hết hạn mới đã có hiệu lực.

Cấu hình tự động reload qua Deploy Hook của Certbot

Để không bao giờ phải nhớ lệnh reload thủ công mỗi khi gia hạn, hãy cấu hình Deploy Hook cho Certbot trong thư mục /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh:

#!/bin/bash
systemctl reload nginx

Cấp quyền thực thi: sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh. Mỗi khi Certbot tự động gia hạn thành công, script này sẽ tự động chạy để Nginx nạp chứng chỉ mới ngay lập tức.

Bước 6: Khắc phục lỗi khi tiến trình tự động gia hạn (Certbot) thất bại

Nếu Certbot không thể tự động gia hạn chứng chỉ, hãy chạy thử nghiệm bằng cờ --dry-run để đọc log lỗi mà không lo bị chạm giới hạn tần suất (Rate Limit) của Let's Encrypt:

sudo certbot renew --dry-run

Với phương thức xác thực HTTP-01 phổ biến nhất, Let's Encrypt sẽ gửi yêu cầu kiểm tra tệp token qua cổng 80 tại đường dẫn http://tenmien.com/.well-known/acme-challenge/<token>.

Các nguyên nhân hàng đầu khiến quá trình này thất bại:

• Cổng 80 bị chặn trên Firewall: Kiểm tra UFW hoặc Cloud Firewall xem cổng 80 có đang mở hay không theo hướng dẫn tại bài Firewall VPS nên mở những cổng nào?.
• Bản ghi DNS IPv6 trỏ sai: Nếu tên miền có bản ghi AAAA trỏ về một địa chỉ IPv6 không tồn tại hoặc trỏ sang máy khác, máy chủ Let's Encrypt mặc định ưu tiên thử IPv6 trước và sẽ báo lỗi timeout.
• Quy tắc chuyển hướng Nginx chặn đường dẫn challenge: Đảm bảo khối cấu hình Nginx không chuyển hướng hoặc chặn truy cập vào thư mục /.well-known/acme-challenge/.

Bước 7: Kiểm tra sự đồng nhất giữa các địa chỉ IP và máy chủ

Nếu một số người dùng báo lỗi SSL trong khi bạn kiểm tra trên máy cá nhân vẫn thấy bình thường:

• Kiểm tra cả 2 bản ghi IPv4 (A) và IPv6 (AAAA) của tên miền. Đảm bảo cả hai đều trỏ về đúng máy chủ hiện tại.
• Nếu bạn có cụm nhiều máy chủ nằm sau Load Balancer, kiểm tra xem có máy chủ backend nào bị sót chưa được đồng bộ tệp chứng chỉ mới hay không.
• Kiểm tra cả hai phiên bản tên miền có www và không có www. Cả hai tên miền này đều phải nằm trong danh sách SAN của chứng chỉ.

Checklist kiểm tra và phục hồi sự cố SSL/TLS

• ☐ Đã dùng lệnh openssl s_client kèm -servername kiểm tra trực tiếp từ môi trường mạng bên ngoài.
• ☐ Đã xác nhận ngày hết hạn (notAfter) và danh sách tên miền (SAN) trên chứng chỉ.
• ☐ Tệp cấu hình Nginx đang trỏ tới fullchain.pem thay vì cert.pem để đảm bảo chuỗi Intermediate CA đầy đủ.
• ☐ Nếu dùng Cloudflare: đã phân biệt rõ lỗi tại Edge Certificate hay lỗi 526 tại Origin Certificate.
• ☐ Đã kiểm tra cú pháp bằng nginx -t và chạy systemctl reload nginx sau khi gia hạn chứng chỉ trên đĩa.
• ☐ Đã cấu hình Deploy Hook cho Certbot để tự động reload Nginx sau mỗi lần gia hạn.
• ☐ Đã kiểm tra cổng 80 trên firewall để đảm bảo quá trình xác thực HTTP-01 challenge không bị chặn.
• ☐ Đã kiểm tra đồng bộ cả bản ghi IPv4 và IPv6 (AAAA).
• ☐ Đã thiết lập hệ thống giám sát cảnh báo hạn chứng chỉ trước ít nhất 15–30 ngày theo tiêu chuẩn tại bài Nên monitoring những gì trên một VPS chạy website?.

Việc quản lý chứng chỉ SSL/TLS ngày nay không còn là thao tác thủ công định kỳ mỗi năm một lần, mà là một quy trình tự động hóa khép kín. Bằng cách định vị chính xác tầng phát sinh lỗi và thiết lập cơ chế tự động nạp lại chứng chỉ bài bản, bạn sẽ loại bỏ hoàn toàn các cảnh báo bảo mật gián đoạn trải nghiệm của người dùng. Khi sự cố SSL làm tê liệt truy cập trên diện rộng, bạn nên áp dụng Quy trình 30 phút đầu khi website gặp sự cố để khoanh vùng và xử lý có kiểm soát.

Nguồn tham khảo

• OpenSSL Documentation — s_client manual
• Nginx Documentation — Module ngx_http_ssl_module
• Let's Encrypt Documentation — Chain of Trust
• Certbot Documentation — Automated Renewal & Renewal Hooks
• Cloudflare Documentation — Troubleshooting Cloudflare 526 errors