Lỗ hổng thu hồi chứng chỉ macOS trong các công cụ dòng lệnh

Vào ngày 19 tháng 10 năm 2026, Apple đã tự động chặn mười hai chứng chỉ bị xâm phạm, tiếp theo là việc chặn chứng chỉ emSign ECC Root CA - G3 vào ngày 23 tháng 10. Trong khi Safari và hầu hết các ứng dụng gốc cập nhật cài đặt tin cậy ngay lập tức, các công cụ dòng lệnh dựa vào kho lưu trữ chứng chỉ tĩnh vẫn dễ bị tổn thương. Sự không nhất quán này tạo ra một thực tế phân tách, nơi cùng một máy tính có thể từ chối một chứng chỉ trong trình duyệt nhưng lại chấp nhận nó trong phiên terminal.

Chuyện gì đã xảy ra

Vấn đề cốt lõi bắt nguồn từ cách các thành phần phần mềm khác nhau trên macOS xác minh chứng chỉ số. Các framework bảo mật của Apple, vốn hỗ trợ Safari, Mail và nhiều ứng dụng khác, sử dụng một hệ thống động để kiểm tra danh sách chặn của Apple và thực hiện các kiểm tra thu hồi trực tuyến. Tuy nhiên, một số công cụ đi kèm với macOS và Xcode Command Line Tools không sử dụng hệ thống động này. Thay vào đó, chúng đọc một tệp tĩnh được đặt tại /etc/ssl/cert.pem. Tính đến tuần mà Apple công bố cảnh báo, tệp này chưa được làm mới để phản ánh các lệnh chặn mới. Apple xác nhận trong bài viết hỗ trợ 149555 rằng các công cụ này không kiểm tra danh sách chặn hoặc xác minh xem một chứng chỉ có bị thu hồi hay không.

Sự phân mảnh này dẫn đến các báo cáo mâu thuẫn từ những người vận hành và nhà phát triển. Một số ghi nhận rằng các lệnh curl và git tích hợp sẵn của họ vẫn tiếp tục kết nối tới các máy chủ sử dụng các chứng chỉ bị chặn, trong khi những người khác khẳng định các công cụ này tôn trọng cài đặt tin cậy của hệ thống. Sự nhầm lẫn có thể xuất phát từ sự khác biệt giữa các phiên bản macOS, việc sử dụng các công cụ cài đặt qua Homebrew so với các nhị phân hệ thống, hoặc hiểu lầm về kho lưu trữ chứng chỉ mà một nhị phân cụ thể tham chiếu. Ví dụ, Homebrew duy trì gói chứng chỉ riêng tại /opt/homebrew/opt/ca-certificates, được cập nhật độc lập với các bản cập nhật hệ điều hành của Apple. Tương tự, các runtime ngôn ngữ như Python thường đóng gói các cơ quan cấp chứng chỉ (CA) riêng thông qua các gói như certifi, tạo ra một bề mặt tin cậy cô lập khác nữa.

Chi tiết chính

• Apple đã chặn mười hai chứng chỉ vào ngày 19 tháng 10 năm 2026 và chứng chỉ emSign ECC Root CA - G3 vào ngày 23 tháng 10 năm 2026.
• Các công cụ đọc /etc/ssl/cert.pem không kiểm tra danh sách chặn của Apple hoặc thực hiện các kiểm tra thu hồi.
• Việc khắc phục thủ công liên quan đến việc xóa các chứng chỉ gốc khỏi tệp tĩnh, nhưng các bản cập nhật phần mềm macOS có thể ghi đè tệp này.
• Có ít nhất bốn trình xác minh riêng biệt tồn tại trên một máy Mac: các framework của Apple, LibreSSL hệ thống, gói của Homebrew và gói của runtime ngôn ngữ.
• Apple khuyên quản trị viên nên kiểm tra lại tệp chứng chỉ sau mỗi lần cập nhật hệ điều hành, vì các bản vá có thể hoàn nguyên những thay đổi thủ công.
• Các báo cáo mâu thuẫn về hành vi của curl cho thấy sự biến thiên trong nguồn gốc công cụ hoặc phiên bản macOS giữa người dùng.

Bối cảnh

Việc thu hồi chứng chỉ không phải là thuộc tính cố hữu của bản thân chứng chỉ, mà là quyết định của bên xác minh đang kiểm tra nó. Khi một cơ quan cấp chứng chỉ (CA) bị lộ khóa hoặc cấp phát chứng chỉ sai lệch, họ sẽ thu hồi chúng. Tuy nhiên, để một client tôn trọng việc thu hồi này, nó phải tham khảo một danh sách hiện hành các chứng chỉ bị thu hồi hoặc kiểm tra trực tuyến theo thời gian thực. Trong hệ sinh thái macOS, quy trình này bị phân mảnh. Hệ thống keychain của Apple được thiết kế để luôn cập nhật và tự động, nhưng các công cụ cũ và trình quản lý gói của bên thứ ba thường dựa vào các ảnh chụp tĩnh (static snapshots) của các root đáng tin cậy. Những ảnh chụp này trở nên lỗi thời cho đến khi được cập nhật rõ ràng, tạo ra các cửa sổ dễ bị tổn thương nơi các chứng chỉ đã bị thu hồi vẫn được chấp nhận là hợp lệ.

Tại sao điều này quan trọng

Đối với các đội ngũ quản lý hạ tầng tự host hoặc phát triển phần mềm trên macOS, sự phân mảnh này đặt ra rủi ro bảo mật đáng kể. Nếu các script triển khai, pipeline CI/CD hoặc công cụ giám sát của bạn dựa vào các tiện ích dòng lệnh như curl hoặc git, chúng có thể tiếp tục tin tưởng các chứng chỉ bị xâm phạm ngay cả sau khi Apple đã chặn chúng. Điều này có nghĩa là các hệ thống tự động của bạn có thể đang giao tiếp với các tác nhân độc hại hoặc endpoint không an toàn mà không đưa ra bất kỳ cảnh báo nào. Sự im lặng của các công cụ này rất nguy hiểm vì chúng báo cáo kết nối thành công, che giấu sự thất bại trong tin cậy nền tảng.

Hơn nữa, giải pháp được khuyến nghị—chỉnh sửa thủ công tệp chứng chỉ—rất mong manh. Vì các bản cập nhật macOS có thể khôi phục phiên bản gốc, chưa được vá của /etc/ssl/cert.pem, một máy tính được bảo mật hôm qua có thể lại trở nên dễ bị tổn thương hôm nay sau một bản cập nhật hệ thống thường xuyên. Nếu không có sự xác minh liên tục, quản trị viên không thể chắc chắn về trạng thái tin cậy của máy móc của họ. Sự không chắc chắn này làm phức tạp hóa việc phản ứng sự cố và kiểm toán tuân thủ, vì hai máy tính trông giống hệt nhau có thể có tư thế bảo mật hoàn toàn khác nhau liên quan đến việc xác thực chứng chỉ.

Bạn có thể làm gì

• Xác định kho lưu trữ chứng chỉ nào mà các công cụ quan trọng của bạn đang sử dụng bằng cách chạy các bài kiểm tra kết nối chi tiết (verbose) và tìm kiếm đầu ra CAfile hoặc CApath.
• So sánh kết quả của security verify-cert với các công cụ dòng lệnh của bạn để phát hiện sự không nhất quán trong các quyết định tin cậy.
• Nếu bạn vá thủ công /etc/ssl/cert.pem, hãy ghi lại hash và ngày của tệp, đồng thời xác minh lại nó sau mỗi lần cập nhật phần mềm macOS.
• Cân nhắc trỏ các công cụ đến một gói chứng chỉ duy nhất, được kiểm soát bằng cách sử dụng các biến môi trường như CURL_CA_BUNDLE hoặc SSL_CERT_FILE.
• Giám sát các dịch vụ hướng ra ngoài của bạn về hiệu lực và hạn chót của chứng chỉ để đảm bảo hạ tầng của bạn vẫn an toàn.
• Kiểm toán các gói chứng chỉ đặc thù cho từng ngôn ngữ, chẳng hạn như certifi của Python, và cập nhật chúng độc lập với hệ điều hành.