Đã kiểm tra đến ngày 31 tháng 10 năm 2026.

Ngày 20 tháng 10 năm 2026, Cloudflare công bố rằng tám khóa ký trung gian của tổ chức cấp chứng chỉ eMudhra bị yếu hoặc bị lộ. Ai nắm được các khóa này có thể tạo chứng chỉ giả. Chứng chỉ giả có được chấp nhận hay không phụ thuộc vào client, tức là phía khởi tạo kết nối TLS: client đó phải vẫn còn tin cậy chuỗi ký bị ảnh hưởng, và không bắt buộc kiểm tra Certificate Transparency, như bài tiếp theo ngày 30 tháng 10 của Cloudflare giải thích. Vấn đề nằm ở xác thực chứng chỉ, không phải thuật toán mã hóa bên trong TLS. Để dùng chứng chỉ giả nghe lén lưu lượng thật, kẻ tấn công còn phải đứng được trên đường truyền mạng hoặc đường định tuyến, nên đây không phải tình huống bất kỳ khách truy cập nào cũng đọc được lưu lượng của bạn. Các báo cáo của Cloudflare mô tả sự cố của một tổ chức cấp chứng chỉ; chúng không chẩn đoán cho bất kỳ website cụ thể nào, kể cả website của bạn.

Sự cố này có thể ảnh hưởng cả doanh nghiệp chưa từng mua chứng chỉ eMudhra. Website của bạn đưa ra chứng chỉ, nhưng máy chủ của bạn cũng đóng vai trò client khi gọi cổng thanh toán, API vận chuyển, dịch vụ email hay webhook. Nếu kho tin cậy (trust store, nơi lưu danh sách các tổ chức cấp chứng chỉ mà hệ thống tin tưởng) trên client đó vẫn chấp nhận chuỗi ký bị ảnh hưởng, rủi ro nằm ở phía bạn. Đây là suy luận của chúng tôi về cách kho tin cậy hoạt động, không phải khẳng định về một nhà cung cấp cụ thể.

Danh sách kiểm tra cho chủ website và đơn vị hosting

  1. Kiểm kê chuỗi chứng chỉ. Kiểm tra riêng chuỗi trên máy chủ gốc và chuỗi mà khách truy cập nhìn thấy, vì proxy có thể đưa ra chuỗi khác. Nếu xuất hiện chứng chỉ trung gian eMudhra bị ảnh hưởng, hãy đề nghị đơn vị cấp hoặc nhà cung cấp thay bằng chuỗi hợp lệ, được tin cậy. Đây là khuyến nghị vận hành của chúng tôi sau đợt thu hồi, không phải khẳng định mọi chứng chỉ eMudhra đều bị ảnh hưởng.

  2. Kiểm kê các TLS client. Liệt kê runtime, container, tác vụ nền, cron script và SDK có gọi HTTPS ra ngoài. Nhiều thành phần đóng gói kho CA riêng. Giao trách nhiệm rõ tên người cho từng mục.

  3. Cập nhật theo hướng dẫn chính thức. Thông báo ngày 20 tháng 10 của Cloudflare nêu cloudflared 2026.10.2 là phiên bản tối thiểu. Hãy chạy ít nhất bản vá đó hoặc một bản phát hành mới hơn đã vá và còn được hỗ trợ, đồng thời cập nhật và triển khai lại image container. Phiên bản tối thiểu của WARP và ứng dụng 1.1.1.1 khác nhau theo nền tảng, nên hãy theo bài gốc thay vì giả định một phiên bản khắc phục cho tất cả.

  4. Vá xong thì bảo đảm bản vá có hiệu lực. Cập nhật hệ điều hành, runtime ngôn ngữ, thư viện HTTP và kho CA tùy chỉnh. Tùy từng ứng dụng, gói đã cập nhật trên đĩa có thể cần build lại, nạp lại, khởi động lại hoặc triển khai lại thì dịch vụ đang chạy mới thực sự dùng đến. Chỉ cập nhật hệ điều hành hay SDK có thể bỏ sót kho đóng gói sẵn.

  5. Rà soát cấu hình origin trên Cloudflare theo hai phần riêng. Về phía máy chủ, nếu dùng chế độ Full (strict) với chứng chỉ origin tùy chỉnh, hãy xác nhận chuỗi mà origin của bạn đưa ra cho Cloudflare còn hợp lệ và được tin cậy. Về phía client, nếu bạn đã tải lên một CA để xác thực chứng chỉ client cho mTLS, đó là một kho tin cậy riêng với vai trò riêng; hãy rà soát nó độc lập. Không hạ chế độ TLS hay tắt xác minh chỉ để lỗi biến mất.

  6. Thử đúng đường tích hợp thật. Chạy một phép thử luồng nghiệp vụ vô hại và được phép, như thanh toán sandbox hoặc gọi API thử. Ổ khóa xanh trên trình duyệt hay lệnh curl thành công không chứng minh mọi client đã an toàn.

  7. Giám sát và lưu bằng chứng. Theo dõi lỗi chứng chỉ trong log và cảnh báo. Nếu có dấu hiệu đáng ngờ, giữ lại bằng chứng và điều tra. Vá xong không phải bằng chứng là chưa bị xâm nhập.

  8. Duy trì kế hoạch khôi phục đã được kiểm chứng. Trước khi thay đổi kho tin cậy hoặc triển khai lại, hãy xác nhận bạn biết cách quay về trạng thái hoạt động đã biết và bản sao lưu đã thực sự được thử khôi phục. Nếu một thay đổi làm hỏng kết nối, hãy sửa nguyên nhân. Không khôi phục lại cấu hình tin cậy cũ còn lỗ hổng như một cách lách tạm.

Cloudflare báo cáo gì ngày 30 tháng 10

Trong bài tiếp theo, Cloudflare cho biết trong số các handshake họ quan sát được, có khoảng 160 handshake đưa ra chứng chỉ giả được tạo sau khi khóa bị lộ. Họ không tìm thấy bằng chứng các chứng chỉ này được dùng để đánh chặn hay nghe lén kết nối của Cloudflare, nhưng không thể loại trừ khả năng đánh chặn có chủ đích. Hostname không khớp và hành vi default-server ủng hộ nhận định này. Cloudflare nói các hệ thống ưu tiên cao đã được vá trong khi một số ticket tác động thấp còn mở, và yêu cầu một số khách hàng cập nhật client cùng cấu hình tin cậy tùy chỉnh. Bảo vệ ở biên không phải bằng chứng rằng origin, API client hay kho tin cậy tùy chỉnh của bạn đã được vá.

Liên hệ với hệ thống hiện có của bạn

Nếu bạn đã chạy sau Cloudflare, bài hướng dẫn Cloudflare edge cho website doanh nghiệp giải thích proxy bao phủ và không bao phủ những gì. Để phát hiện lỗi chứng chỉ trước khi khách hàng gặp phải, xem giám sát vượt ra ngoài uptime.

Nguồn được kiểm tra tính đến ngày 31 tháng 10 năm 2026. ViWeb Technology đăng bài này như hướng dẫn thực hành, không phải cam kết bảo mật.