Quay lại

2026/10/30

Trình duyệt được bảo vệ chỉ trong vài giờ. Còn Java doanh nghiệp thì sao? LOGIQ đã ứng phó sự cố chứng chỉ eMudhra như thế nào

Trình duyệt chặn các CA trung gian eMudhra bị xâm phạm trong vài giờ, nhưng mỗi JDK có kho tin cậy riêng. Azul, BellSoft, LOGIQ đã làm gì và cần kiểm tra gì ngay.

Điểm chính

  • Ngày 17 tháng 10 năm 2026, Mozilla nhận được báo cáo rằng khóa riêng của tám chứng chỉ CA trung gian của eMudhra đã bị xâm phạm. Các trình duyệt đã chặn chúng trong vòng vài giờ đến vài ngày. eMudhra cho biết họ không nhận thấy bằng chứng nào cho thấy các khóa này đã bị khai thác.
  • Java không sử dụng các quyết định tin cậy của trình duyệt hay của hệ điều hành. Mỗi JDK, cũng như mỗi container image hoặc ứng dụng đóng gói kèm JDK, đều mang kho chứng chỉ tin cậy (trust store) riêng. Mỗi bản như vậy đều cần được cập nhật riêng.
  • Azul đã phát hành hai bản cập nhật Zulu ngoài chu kỳ, vào ngày 21 và ngày 24 tháng 10. Bản thứ hai ra đời vì bản sửa lỗi đầu tiên chưa đủ, nên giải pháp tạm thời ngày 21 tháng 10 không còn đủ nếu chỉ dùng riêng.
  • BellSoft liệt kê các bản build Liberica đã được sửa cho Java 8, 11, 17, 21, 25 và 27. LOGIQ đã nhận các bản build này qua kênh hỗ trợ BellSoft của chúng tôi và cung cấp chúng cho khách hàng.
  • Việc cần làm: tìm mọi Java runtime bạn đang chạy, kiểm tra chính xác nhà cung cấp và bản build, chuyển sang bản build đã sửa của nhà cung cấp đó, kiểm thử các kết nối TLS và tiếp tục theo dõi các bản phát hành ngoài chu kỳ.

Chuyện gì đã xảy ra

Vào thứ Bảy, ngày 17 tháng 10 năm 2026, lúc 20:06 UTC, Mozilla nhận được báo cáo rằng khóa riêng của tám chứng chỉ trung gian của eMudhra đã bị xâm phạm. Mozilla đã chặn tám chứng chỉ này trong Firefox thông qua OneCRL, danh sách thu hồi tập trung của mình, và bản cập nhật đã đến với người dùng có cài đặt tiêu chuẩn trước 22:59 UTC, chưa đầy ba giờ sau đó. Mozilla công bố sự cố vào ngày 20 tháng 10. Mozilla cũng phát hành các bản Firefox point release cho những người dùng có cài đặt chặn bản cập nhật OneCRL, đồng thời gỡ chứng chỉ gốc đã ký các chứng chỉ trung gian này khỏi kho tin cậy NSS.

Rủi ro ở đây là giả mạo chứng chỉ. Bất kỳ ai nắm giữ một trong các khóa này đều có thể cấp chứng chỉ HTTPS cho một trang web mà họ không kiểm soát. Nếu họ còn có thể chen vào giữa máy khách và trang web đó, họ có thể mạo danh trang web và đọc hoặc thay đổi lưu lượng.

Cho đến nay chưa có bằng chứng nào cho thấy điều này đã xảy ra. Trong thông báo về sự cố, eMudhra cho biết tám chứng chỉ trung gian đã bị thu hồi vào ngày 18 tháng 10, không chứng chỉ nào trong số đó từng cấp chứng chỉ end-entity, và họ “không nhận thấy bằng chứng nào cho thấy các khóa yếu đã bị bất kỳ ai khôi phục hoặc khai thác trước khi vấn đề được công bố.” eMudhra mô tả nguyên nhân là các khóa yếu được tạo ra trong một buổi key ceremony năm 2025. Họ cho biết chưa xác nhận được nguyên nhân gốc rễ chính xác và cuộc điều tra vẫn đang tiếp diễn. Các chương trình chứng chỉ gốc của trình duyệt đã ngừng tin cậy chứng chỉ gốc eMudhra phía trên các chứng chỉ trung gian này như một biện pháp phòng ngừa.

Vì vậy, bài viết này nói về việc đóng lại một khoảng thời gian bị phơi nhiễm, chứ không phải về một cuộc tấn công đã được xác nhận.

Vì sao Java cần bản sửa lỗi riêng

Trình duyệt và hệ điều hành có cơ chế tự động để ngừng tin cậy một tổ chức cấp chứng chỉ, và chúng đã dùng các cơ chế này rất nhanh. Theo mô tả sự cố của Azul, Chrome đã chặn các chứng chỉ ngay trong ngày, Apple vào ngày 19 tháng 10 và Microsoft vào ngày 20 tháng 10.

Java không thừa hưởng bất kỳ điều nào trong số này. Một JDK quyết định tin cậy chứng chỉ nào dựa trên các tệp của chính nó:

  • Kho tin cậy riêng. Mỗi JDK đi kèm tệp cacerts riêng. Việc cập nhật bộ chứng chỉ của hệ điều hành hay khởi động lại trình duyệt không làm thay đổi tệp này.
  • Mặc định không kiểm tra thu hồi. Như tài liệu của Azul nêu rõ, Java tin cậy các chứng chỉ gốc mà các chứng chỉ trung gian này liên kết tới và “mặc định không kiểm tra thu hồi.” Việc eMudhra thu hồi các chứng chỉ trung gian tự nó không bảo vệ được một máy khách Java.
  • Nhiều bản sao. Một máy chủ có thể chạy JDK của hệ thống, một JDK đóng gói bên trong ứng dụng, một runtime tạo bằng jlink và nhiều container image, mỗi thứ có bản sao kho tin cậy riêng. Mỗi bản sao vẫn bị phơi nhiễm cho đến khi được cập nhật hoặc build lại.

Vì vậy, một dịch vụ Java thực hiện các kết nối TLS ra ngoài vẫn có thể chấp nhận chứng chỉ giả mạo ngay cả khi mọi trình duyệt trong tòa nhà đã được bảo vệ. Đó chính là khoảng trống mà bài viết này đề cập.

Hai bản cập nhật khẩn cấp từ Azul

Azul đã phát hành hai bản cập nhật ngoài chu kỳ cho Azul Zulu sau bản phát hành hằng quý tháng 10:

  • Ngày 21 tháng 10: bản cập nhật ngoài chu kỳ đầu tiên bổ sung tám chứng chỉ trung gian bị xâm phạm vào danh sách chặn của JDK (blocked.certs trong JDK 11 trở lên, blacklisted.certs trong các phiên bản cũ hơn). Bản này áp dụng cho Zulu 27, 25, 21, 17, 11, 8, 7 và 6. Danh sách CVE của Azul ghi nhận bản này là CVE-2026-91403. Đối với các runtime chưa thể cập nhật ngay, Azul cũng công bố một giải pháp tạm thời thủ công thay thế tệp danh sách chặn.
  • Ngày 24 tháng 10: Azul nhận thấy danh sách chặn chưa khắc phục triệt để vấn đề. Bản cập nhật ngoài chu kỳ thứ hai sửa CVE-2026-114820 (JSSE, điểm cơ sở 9.1) bằng cách gỡ hẳn một số chứng chỉ CA khỏi cacerts. Tại thời điểm viết bài, các bản build này có sẵn cho dòng CPU chỉ gồm bản vá bảo mật của Azul, trên cả nền CPU tháng 10 năm 2026 (ví dụ Zulu 21.53.114, 17.69.114, 11.91.114 và 8.97.0.112) lẫn nền CPU tháng 7 năm 2026. Azul cho biết các bản build PSU “nhiều khả năng sẽ” được phát hành sau trong một bản cập nhật riêng.

Bản cập nhật ngày 24 tháng 10 làm thay đổi khuyến nghị. Trang giải pháp tạm thời của Azul hiện cảnh báo rằng giải pháp này “không còn khắc phục triệt để vấn đề,” và Azul yêu cầu mọi khách hàng cập nhật lên bản phát hành mới nhất. Nếu bạn đã áp dụng bản cập nhật ngày 21 tháng 10 hoặc giải pháp tạm thời, bạn vẫn cần bản build ngày 24 tháng 10. Trong bài viết của mình, Azul cho biết họ mất khoảng 12 giờ kể từ khi quyết định build lại cho đến khi các bản build chỉ gồm bản vá bảo mật đến tay khách hàng.

BellSoft đã phát hành gì cho Liberica JDK

BellSoft đã công bố bản phát hành Liberica JDK định kỳ tháng 10 năm 2026 vào ngày 21 tháng 10. Bản phát hành hằng quý này liệt kê 52 CVE đã được sửa và bao gồm các bản build CPU cho Java 6 và 7 (6u521 và 7u521). Ghi chú phát hành của bản này không đề cập đến vấn đề eMudhra.

BellSoft đề cập đến eMudhra trong một hướng dẫn riêng, “Distrusting compromised eMudhra intermediates in Java” (cập nhật lần cuối ngày 27 tháng 10). Hướng dẫn này liệt kê các bản build đã sửa là Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 và 27.0.1.0.3+5. Đối với các hệ thống chưa thể cập nhật, hướng dẫn đưa ra một biện pháp giảm thiểu tạm thời: gỡ các chứng chỉ gốc bị ảnh hưởng khỏi kho tin cậy. Hướng dẫn cũng cảnh báo rằng việc này có thể làm hỏng các chuỗi chứng chỉ hợp lệ và cần được kiểm thử trước.

Có hai điểm quan trọng khi so sánh các nhà cung cấp:

  • Danh sách CVE không giống nhau. Azul và BellSoft mỗi bên công bố danh sách CVE riêng cho chu kỳ tháng 10, và số lượng cũng như ghi chú đều khác nhau. Hai mã CVE của Azul nêu trên lấy từ hồ sơ của Azul. Hướng dẫn của BellSoft không trích dẫn chúng. Hãy kiểm tra ghi chú phát hành của chính nhà cung cấp của bạn để biết chính xác các bản sửa lỗi trong bản build của bạn, và đừng mặc định rằng danh sách của nhà cung cấp này áp dụng cho JDK của nhà cung cấp khác.
  • Java 6 và 7 không có trong danh sách eMudhra của BellSoft. Các bản build Java 6 và 7 mới nhất của BellSoft đã có sẵn, nhưng danh sách bản build đã sửa trong hướng dẫn eMudhra của hãng bắt đầu từ Java 8. Nếu bạn chạy Liberica 6 hoặc 7, hãy hỏi xem bản build của bạn đã bao gồm thay đổi kho tin cậy hay chưa trước khi dựa vào nó, hoặc áp dụng biện pháp giảm thiểu của nhà cung cấp. Azul liệt kê các bản build ngày 24 tháng 10 cho Zulu 6 và 7.

LOGIQ đã ứng phó như thế nào

Chúng tôi phân phối các bản build Java từ BellSoft và Azul cho khách hàng và hỗ trợ họ chuyển đổi khỏi các phiên bản Oracle JDK cũ. Dưới đây là những việc chúng tôi đã làm, kèm trạng thái của từng hạng mục tại thời điểm viết bài (ngày 29 tháng 10).

Đã hoàn thành

  • Ngày 21–22 tháng 10: xem xét thông báo của nhà cung cấp. Chúng tôi đã nhận và xem xét thông báo ngoài chu kỳ ngày 21 tháng 10 của Azul và thông báo phát hành tháng 10 năm 2026 của BellSoft. Ngay trong ngày, chúng tôi đã mở các tác vụ tải xuống và đưa vào kho phân phối cho cả hai nhà cung cấp. Chúng tôi xử lý hai bản phát hành một cách riêng biệt và không mặc định rằng bản phát hành hằng quý của BellSoft có cùng bản sửa lỗi eMudhra như của Azul.
  • Ngày 23 tháng 10: chuẩn bị các bản build Liberica hằng quý. Chúng tôi đã tải các bản build Liberica JDK tháng 10 năm 2026 từ cổng hỗ trợ của BellSoft và đưa chúng vào kho mà khách hàng của chúng tôi tải xuống.
  • Ngày 24–25 tháng 10: theo dõi bản cập nhật thứ hai của Azul. Chúng tôi đã tiếp nhận thông báo ngày 24 tháng 10 của Azul, bao gồm khuyến nghị cập nhật ngay cả khi đã cài bản build ngày 21 tháng 10.
  • Ngày 27–28 tháng 10: nhận các bản build Liberica đã sửa thông qua BellSoft. Thông qua quan hệ hỗ trợ thương mại, chúng tôi đã đề nghị BellSoft cung cấp các bản build mới nhất trên cổng hỗ trợ của chúng tôi. BellSoft đã tải chúng lên vào ngày 28 tháng 10, bao gồm các bản build đã sửa cho Java 8, 11, 17, 21, 25 và 27 cùng các bản build Java 6 và 7 mới nhất. Một số khách hàng vẫn cần Java 8 bản 32-bit, vì vậy chúng tôi cũng đề nghị BellSoft bổ sung các bộ cài 8u513+9 bản 32-bit cho Windows và Linux vào cổng của chúng tôi. BellSoft đã bổ sung ngay trong ngày.
  • Ngày 28–29 tháng 10: cập nhật kho phân phối và bảng ánh xạ chuyển đổi. Chúng tôi đã đưa các bản build này vào kho tải xuống dành cho khách hàng và cập nhật hướng dẫn chuyển đổi từ Oracle JDK sang Liberica để trỏ tới chúng, với một kỹ sư thứ hai rà soát bản cập nhật.

Khách hàng dùng Azul Zulu

Các bản build ngày 21 và ngày 24 tháng 10 của Azul được cung cấp cho người đăng ký Azul thông qua Azul. Bản build phù hợp phụ thuộc vào phiên bản Java của bạn, việc bạn dùng dòng CPU hay PSU, và bạn đang ở nền nào (tháng 10 hay tháng 7). Hãy kiểm tra ghi chú phát hành của Azul cho chính xác bản build của bạn, hoặc liên hệ với chúng tôi để được hỗ trợ xác định.

Java 6 và 7 đời cũ

Một số khách hàng vẫn chạy Java 6 hoặc 7, thường là trong các ứng dụng không thể chuyển đổi nhanh. Oracle không còn cung cấp bản cập nhật công khai cho các phiên bản này, nhưng không phải là không có lựa chọn. Chúng tôi hỗ trợ khách hàng chuyển từ các bản build Oracle JDK 6 và 7 cũ sang các bản build Liberica JDK 6 và 7 mới nhất, và các bản build tháng 10 năm 2026 của BellSoft cho cả hai phiên bản đều có sẵn cho chúng tôi qua cổng hỗ trợ của BellSoft. Khi thiếu một bản sửa lỗi hoặc gói mà chúng tôi cần cho các phiên bản này, chúng tôi chuyển yêu cầu lên BellSoft qua kênh hỗ trợ thương mại. Đối với sự cố này, hãy xem lưu ý ở trên: xác nhận bản build Java 6 hoặc 7 của bạn đã bao gồm thay đổi kho tin cậy liên quan đến eMudhra trước khi dựa vào nó.

Những việc bạn nên làm ngay

1. Tìm mọi Java runtime

Liệt kê mọi nơi Java đang chạy, không chỉ JDK của hệ thống. Điều đó bao gồm máy chủ ứng dụng, runtime đóng gói bên trong sản phẩm của nhà cung cấp, image tạo bằng jlink, các CI build agent và mọi container image. Trên Linux, lệnh sau tìm các tệp thực thi Java trên một máy chủ:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Với container image, hãy chạy kiểm tra bên trong image, ví dụ docker run --rm --entrypoint java <image> -version.

2. Kiểm tra chính xác nhà cung cấp và bản build

Chỉ biết phiên bản chính là chưa đủ. Bạn cần biết nhà cung cấp và số build đầy đủ để đối chiếu với danh sách bản build đã sửa của nhà cung cấp:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Để kiểm tra nhanh, bạn cũng có thể liệt kê các chứng chỉ gốc eMudhra (emSign) trong kho tin cậy của một runtime:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

Trong các thử nghiệm của chúng tôi với container image công khai của BellSoft, một bản build Liberica 21.0.10 cũ hơn liệt kê năm chứng chỉ gốc emSign, trong khi các bản build đã sửa 21.0.13.0.3+5 và 8u513 không liệt kê chứng chỉ nào. Kết quả rỗng là dấu hiệu tốt nhưng chưa phải là bằng chứng. Ví dụ, bản sửa lỗi ngày 21 tháng 10 của Azul đã chặn các chứng chỉ trung gian mà không gỡ chứng chỉ gốc. Số build mới là cách kiểm tra đáng tin cậy. Bài viết trước đây của chúng tôi về kiểm tra kho tin cậy Java trình bày các bước kiểm tra chi tiết hơn.

3. Cài bản vá mới nhất phù hợp

  • Azul Zulu: chuyển sang bản build ngoài chu kỳ ngày 24 tháng 10 cho dòng của bạn (CPU hoặc PSU, nền tháng 10 hoặc tháng 7), ngay cả khi bạn đã cài bản build ngày 21 tháng 10 hoặc đã áp dụng giải pháp tạm thời. Nếu bạn dùng bản build PSU, hãy theo dõi bản phát hành PSU tiếp theo của Azul.
  • Liberica JDK: chuyển sang các bản build đã sửa do BellSoft liệt kê (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Nhà cung cấp khác và runtime đóng gói kèm: kiểm tra khuyến cáo của nhà cung cấp đó. JDK nằm trong sản phẩm của bên thứ ba do nhà cung cấp sản phẩm đó cập nhật, chứ không phải qua các bản cập nhật hệ điều hành của bạn.
  • Container: build lại image trên một base image đã được sửa và triển khai lại. Vá một container đang chạy không làm thay đổi image.

4. Kiểm thử TLS trước và trong khi triển khai

Gỡ chứng chỉ gốc khỏi kho tin cậy có thể làm hỏng các kết nối hợp lệ, ví dụ tới các trang web vẫn dùng chứng chỉ liên kết tới các chứng chỉ gốc eMudhra đã bị gỡ. eMudhra cho biết họ đang cấp lại các chứng chỉ khách hàng bị ảnh hưởng từ một hệ thống phân cấp CA thay thế. Trước khi triển khai trên diện rộng, hãy kiểm thử các kết nối TLS ra ngoài mà ứng dụng của bạn phụ thuộc vào, đặc biệt là tới các đối tác hoặc dịch vụ có thể dùng chứng chỉ eMudhra. Triển khai theo từng giai đoạn, khởi động lại các tiến trình Java để chúng nạp kho tin cậy mới, và xác nhận phiên bản đang chạy sau đó.

5. Theo dõi các bản phát hành ngoài chu kỳ

Sự cố này đã dẫn đến hai bản phát hành Java khẩn cấp trong vòng bốn ngày, và có thể còn nhiều bản nữa, chẳng hạn các bản build PSU của Azul. Hãy đăng ký nhận thông báo bảo mật của các nhà cung cấp, kiểm tra trực tiếp trang phát hành của họ thay vì chỉ dựa vào email, và lên kế hoạch cho các bản cập nhật Java ngoài lịch hằng quý.

Bài học

Người dùng Firefox được bảo vệ chỉ trong vài giờ vì trình duyệt có kho tin cậy riêng và một cơ chế tự động để cập nhật kho đó. Java doanh nghiệp có nhiều kho tin cậy, mặc định không kiểm tra thu hồi, và các bản cập nhật phải chờ ai đó cài đặt. Để thu hẹp khoảng trống đó, cần có một bản kiểm kê chính xác, số build chính xác, khả năng tiếp cận nhanh các bản build của nhà cung cấp và một quy trình không phải chờ đến bản vá hằng quý tiếp theo. Nếu bạn cần hỗ trợ tìm hoặc cập nhật các Java runtime trong môi trường của mình, hãy liên hệ LOGIQ.

Tài liệu tham khảo