Chuỗi chứng chỉ SSL là gì? Cách hoạt động

Chuỗi chứng chỉ SSL là gì?

Chuỗi chứng chỉ SSL (còn gọi là chuỗi tin cậy hay đường dẫn chứng nhận) là danh sách có thứ tự các chứng chỉ số nối chứng chỉ SSL/TLS của trang web bạn với một Tổ chức cấp chứng chỉ (CA) gốc đáng tin cậy. Mỗi chứng chỉ trong chuỗi được chứng chỉ phía trên ký số, tạo thành một đường dẫn tin cậy có thể xác minh từ máy chủ của bạn lên tới một CA gốc mà trình duyệt đã tin cậy.

Hãy hình dung nó như một chuỗi bảo chứng. Chứng chỉ máy chủ của bạn nói: "Tôi là example.com." CA trung gian nói: "Tôi bảo chứng cho chứng chỉ của example.com." CA gốc nói: "Tôi bảo chứng cho CA trung gian đó." Trình duyệt của bạn đã tin CA gốc, nên khi lần theo chuỗi chữ ký, nó cũng tin máy chủ của bạn.

Khi bạn truy cập một trang HTTPS, trình duyệt lần theo chuỗi này trong vài mili giây. Nếu mọi mắt xích đều ổn, trang tải mà không có cảnh báo. Nếu một mắt xích bị thiếu, hết hạn hoặc không đáng tin, bạn sẽ thấy một cảnh báo bảo mật như NET::ERR_CERT_AUTHORITY_INVALID thay cho trang.

Ba loại chứng chỉ trong một chuỗi

Mỗi chuỗi có ba loại chứng chỉ, dù máy chủ có thể gửi nhiều hơn một chứng chỉ trung gian:

Chứng chỉ gốc

Chứng chỉ gốc là điểm neo tin cậy ở đỉnh chuỗi. Nó tự ký, nghĩa là Tổ chức cấp chứng chỉ tự ký chứng chỉ của chính mình. Chứng chỉ gốc được cài sẵn trong trình duyệt và hệ điều hành của bạn — bộ sưu tập này gọi là kho tin cậy.

Danh sách gốc riêng của Chrome có khoảng 100 chứng chỉ gốc (Chrome Root Store); Mozilla, Apple và Microsoft có danh sách riêng. Các tổ chức như DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign và Google Trust Services vận hành chứng chỉ gốc. Vì khóa gốc rất có giá trị, các CA giữ chúng ngoại tuyến trong mô-đun bảo mật phần cứng và chỉ dùng để ký chứng chỉ trung gian.

Chứng chỉ trung gian

Chứng chỉ trung gian nằm giữa chứng chỉ gốc và chứng chỉ máy chủ của bạn. CA gốc ký chứng chỉ trung gian, rồi CA trung gian ký các chứng chỉ thực thể cuối (máy chủ). Hầu hết các CA dùng một hoặc hai chứng chỉ trung gian.

Máy chủ web của bạn phải gửi các chứng chỉ trung gian cùng với chứng chỉ leaf trong quá trình bắt tay TLS. Chrome có thể tải một chứng chỉ trung gian bị thiếu và Firefox tải sẵn chúng, nhưng ứng dụng, API client và các thiết bị Android cũ không có cả hai khả năng đó, nên với chúng chuỗi bị đứt.

Chứng chỉ leaf (chứng chỉ máy chủ)

Chứng chỉ leaf (còn gọi là chứng chỉ thực thể cuối hoặc chứng chỉ máy chủ) là chứng chỉ được cài đặt trên máy chủ web. Nó chứa tên miền, khóa công khai, thời hạn hiệu lực và thông tin về bên cấp (CA trung gian đã ký nó).

Đây là chứng chỉ đầu tiên trình duyệt nhận được trong quá trình bắt tay TLS. Trình duyệt sau đó đi lên chuỗi, xác minh từng chữ ký cho đến khi tới được gốc tin cậy.

Chuỗi tin cậy hoạt động như thế nào

Khi trình duyệt kết nối với trang web qua HTTPS, quá trình bắt tay TLS kích hoạt quy trình xác minh chuỗi diễn ra trong vài mili giây:

• Máy chủ gửi các chứng chỉ của nó — leaf trước, rồi các chứng chỉ trung gian.
• Trình duyệt dựng một đường dẫn — từ leaf lên một chứng chỉ gốc trong danh sách của chính nó. Nếu thiếu chứng chỉ trung gian, Chrome tải nó từ địa chỉ ghi trong chứng chỉ (AIA), còn Firefox dùng bộ chứng chỉ tải sẵn của riêng mình; nhiều client khác thì lỗi ngay.
• Kiểm tra chữ ký — mỗi chứng chỉ phải được ký bằng khóa của chứng chỉ phía trên.
• Kiểm tra chứng chỉ gốc — đường dẫn phải kết thúc ở một chứng chỉ gốc trong danh sách của trình duyệt. Gốc không xác định sẽ không qua được.
• Kiểm tra hiệu lực — mọi chứng chỉ phải còn trong thời hạn và chưa bị thu hồi, và leaf phải bao phủ tên trên thanh địa chỉ.

Chuỗi thực tế: 12 trang lớn gửi gì

Ngày 27 tháng 10 năm 2026, chúng tôi đã yêu cầu 12 trang lớn nhất gửi chuỗi của họ (openssl s_client -showcerts, từ hai vị trí). Không trang nào chỉ gửi mỗi leaf, và một số gửi thêm các chứng chỉ ký chéo để thiết bị cũ vẫn tới được một gốc mà chúng biết. Những gì máy chủ gửi có thể thay đổi theo phiên bản TLS, việc client có hỗ trợ ECDSA hay không và vị trí CDN nào phản hồi: ví dụ facebook.com đã gửi 3 chứng chỉ qua TLS 1.2.

Điều gì xảy ra sau khi xác minh

Nếu mọi kiểm tra đều qua, kết nối được tiếp tục. Nếu một kiểm tra thất bại, kể cả ở chứng chỉ trung gian, trình duyệt hiển thị cảnh báo như "Kết nối của bạn không phải là kết nối riêng tư" kèm mã như NET::ERR_CERT_AUTHORITY_INVALID. (Các lỗi xảy ra trước khi xem bất kỳ chứng chỉ nào, ngay trong quá trình bắt tay TLS, hiện mã khác: ERR_SSL_PROTOCOL_ERROR hoặc ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Đó là lý do toàn bộ chuỗi đều quan trọng, không chỉ chứng chỉ leaf. Một chứng chỉ trung gian hết hạn làm hỏng HTTPS giống như chứng chỉ máy chủ hết hạn, trừ khi client dựng được một đường dẫn khác vòng qua nó.

Tại sao chứng chỉ trung gian tồn tại

Về lý thuyết, CA gốc có thể ký trực tiếp mọi chứng chỉ máy chủ, bỏ qua hoàn toàn chứng chỉ trung gian. Nhưng có ba lý do quan trọng tại sao họ không làm vậy:

• Cách ly bảo mật — Khóa riêng của CA gốc được giữ ngoại tuyến trong HSM bên trong két an toàn vật lý. Chúng chỉ được sử dụng để ký chứng chỉ trung gian, không phải hàng triệu chứng chỉ máy chủ riêng lẻ. Điều này giảm đáng kể rủi ro khóa gốc bị xâm phạm.
• Kiểm soát thiệt hại — Nếu CA trung gian bị xâm phạm, chỉ các chứng chỉ của trung gian đó bị ảnh hưởng. CA gốc có thể thu hồi trung gian bị xâm phạm và cấp mới — mà không vô hiệu hóa mọi chứng chỉ đã từng cấp.
• Linh hoạt vận hành — Các CA sử dụng các chứng chỉ trung gian khác nhau cho các mục đích khác nhau: một cho chứng chỉ DV, một cho EV, riêng biệt cho các khu vực hoặc thuật toán khóa khác nhau (RSA vs ECDSA).

Cách kiểm tra chuỗi chứng chỉ SSL

Có ba cách để kiểm tra chuỗi chứng chỉ của trang web, từ công cụ dòng lệnh đến kiểm tra trên trình duyệt.

Phương pháp 1: OpenSSL (dòng lệnh)

Lệnh openssl là cách chi tiết nhất để kiểm tra chuỗi chứng chỉ. Chạy lệnh này trong terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Phương pháp 2: trình xem chứng chỉ của trình duyệt

Mọi trình duyệt lớn đều hiển thị chuỗi mà nó đã dựng (có thể khác với chuỗi máy chủ gửi, nếu nó tự tải chứng chỉ trung gian bị thiếu):

• Chrome: nhấp biểu tượng bên trái địa chỉ → Kết nối này an toàn → Chứng chỉ hợp lệ, rồi mở tab Chi tiết để xem phân cấp chứng chỉ
• Edge: nhấp biểu tượng ổ khóa → "Connection is secure" → biểu tượng chứng chỉ ở đầu bảng
• Firefox: nhấp biểu tượng ổ khóa → "Connection secure" → "More information" → "View Certificate"; mỗi chứng chỉ trong chuỗi có một tab riêng
• Safari (18.4 trở lên): chọn Safari > Chi tiết bảo mật kết nối trên thanh menu (Apple); trên iPhone, chạm vào phía bên trái của trường địa chỉ → "Privacy & Security" → "Connection Security Details"

Phương pháp 3: công cụ kiểm tra SSL DNS Robot

Cách kiểm tra nhanh nhất từ bên ngoài mạng của bạn là công cụ Kiểm tra SSL của chúng tôi: nó hiển thị chuỗi mà máy chủ gửi, việc danh sách gốc của Mozilla, Chrome, Apple và Microsoft có tin cậy nó hay không, cảnh báo khi chuỗi chưa đầy đủ và ngày của từng chứng chỉ. Với các trang sau Cloudflare, nó đọc chứng chỉ từ nhật ký CT công khai, nên ở đó chuỗi do máy chủ gửi không được kiểm tra.

Các lỗi chuỗi chứng chỉ phổ biến và cách sửa

Vấn đề chuỗi chứng chỉ là một trong những nguyên nhân phổ biến nhất gây lỗi HTTPS. Dưới đây là các lỗi bạn có thể gặp và cách giải quyết từng lỗi.

Thiếu chứng chỉ trung gian

Thông báo lỗi: "unable to get local issuer certificate" (curl, Python, PHP), "unable to verify the first certificate" (Node.js) hoặc "incomplete certificate chain"

Nguyên nhân: máy chủ chỉ gửi chứng chỉ leaf. Chrome thường khắc phục bằng cách tự tải chứng chỉ trung gian (trình xác minh của Apple cũng vậy), nên trang có thể trông bình thường trong trình duyệt, trong khi curl trên Linux, Python, Java, các lệnh gọi lại thanh toán và nhiều ứng dụng bị lỗi.

Cách sửa: gửi các chứng chỉ trung gian cùng với leaf. Với Let's Encrypt, hãy trỏ máy chủ tới fullchain.pem thay vì cert.pem; với CA khác, hãy tải chứng chỉ trung gian của họ và đặt sau chứng chỉ của bạn trong một tệp:

cat your-domain.crt intermediate.crt > fullchain.crt

Chứng chỉ tự ký trong chuỗi

Thông báo lỗi: "self-signed certificate in certificate chain" (lỗi OpenSSL 19)

Nguyên nhân: chuỗi kết thúc ở một gốc mà client không tin: một CA riêng hoặc của công ty, hoặc một proxy hay phần mềm diệt virus ký lại lưu lượng bằng gốc của chính nó. Gửi một gốc mà client tin thì vô hại, chỉ là không cần thiết.

Cách sửa: dùng chứng chỉ từ một CA công khai cho các trang công khai, hoặc cài gốc riêng lên các client cần nó. Bỏ gốc khỏi chuỗi của máy chủ thì gọn gàng nhưng không sửa được lỗi này.

Sai thứ tự chứng chỉ

Thông báo lỗi: việc xác minh chuỗi thất bại ở một số client, hoặc họ báo chứng chỉ không đáng tin.

Nguyên nhân: các chứng chỉ trong tệp chuỗi sai thứ tự. TLS 1.3 yêu cầu chứng chỉ của chính máy chủ đứng đầu và các chứng chỉ còn lại theo thứ tự, nhưng cũng bảo client phải chịu được các thứ tự khác (RFC 8446 §4.4.2); client cũ hoặc khắt khe hơn có thể không chịu được.

Cách sửa: đặt chứng chỉ leaf đầu tiên, rồi từng chứng chỉ trung gian, bắt đầu từ chứng chỉ đã ký leaf của bạn.

Chứng chỉ hết hạn trong chuỗi

Thông báo lỗi: "certificate has expired" — nhưng ngày hết hạn của chứng chỉ leaf của bạn trông vẫn ổn.

Nguyên nhân: một chứng chỉ cao hơn trong chuỗi đã hết hạn. Trường hợp nổi tiếng nhất: DST Root CA X3 của IdenTrust, từng ký chéo gốc của Let's Encrypt, hết hạn ngày 30 tháng 9 năm 2021, và các thiết bị không tin ISRG Root X1 (cùng các client dùng OpenSSL 1.0.x) bắt đầu lỗi trên các trang dùng Let's Encrypt.

Cách sửa: tải chứng chỉ trung gian hiện hành từ CA của bạn và thay chứng chỉ cũ. Sau đó dùng công cụ Kiểm tra SSL của chúng tôi để xác minh chuỗi đã cập nhật.

Thực tiễn tốt nhất cho chuỗi chứng chỉ

• Luôn gửi các chứng chỉ trung gian — đừng trông chờ trình duyệt sửa chuỗi; ứng dụng và API client sẽ không làm vậy.
• Gốc là tùy chọn — client dùng bản sao của chính họ, nên gửi một gốc mà họ đã tin chỉ làm tăng dung lượng; gốc ký chéo cho thiết bị cũ là ngoại lệ có chủ ý.
• Giữ đúng thứ tự — leaf trước, rồi các chứng chỉ trung gian từ chứng chỉ đã ký leaf của bạn trở lên.
• Tự động hóa việc gia hạn — chứng chỉ cấp từ tháng 3/2026 có hiệu lực tối đa 200 ngày, giảm xuống 100 ngày vào tháng 3/2027, và Let's Encrypt chuyển sang chứng chỉ 64 ngày vào tháng 2/2027.
• Kiểm tra sau mỗi lần gia hạn hoặc chuyển máy chủ — một CA có thể đổi chứng chỉ trung gian giữa các lần gia hạn. Sau đó hãy chạy trang qua công cụ Kiểm tra SSL.
• Theo dõi từng tên — www, tên miền gốc và từng tên miền phụ có thể được phục vụ bằng các chứng chỉ và chuỗi khác nhau. Công cụ tìm tên miền phụ liệt kê các tên mà chứng chỉ của bạn đã bao phủ, từ nhật ký chứng chỉ công khai.