Tin ngành
Cloudflare ra mắt tính năng giám sát minh bạch chứng chỉ (Certificate Transparency)
(giờ Việt Nam)
Tóm tắt AI
Cloudflare chính thức phát hành công cụ giám sát minh bạch chứng chỉ. Điểm cải tiến quan trọng là hệ thống sẽ lọc bỏ các thông báo về chứng chỉ do chính Cloudflare cấp, giúp các cảnh báo gửi đến bạn trở nên đáng tin cậy và cần được ưu tiên kiểm tra hơn.
Bản dịch AI

Kể từ khi ra mắt tính năng Giám sát Minh bạch Chứng chỉ (Certificate Transparency Monitoring) ở phiên bản beta công khai vào năm 2019, chúng tôi đã gửi email cho người đăng ký bất cứ khi nào một chứng chỉ TLS mới xuất hiện trong nhật ký Minh bạch Chứng chỉ (CT) công khai cho một trong các tên miền của họ. Hiện nay, tính năng này đã được kích hoạt cho hơn 650.000 tên miền khách hàng. Đây là một cảnh báo sớm cho biết có ai đó, ở đâu đó, đã cấp chứng chỉ cho một tên máy chủ (hostname) trong vùng của bạn, giúp bạn có cơ hội phát hiện sớm các chứng chỉ được cấp sai quy định.
Đây là một tín hiệu hữu ích, nhưng nó gặp vấn đề về nhiễu thông tin và chính chúng tôi cũng cảm nhận được điều đó. Cloudflare thay mặt bạn cấp một lượng lớn chứng chỉ: gia hạn Universal SSL, chứng chỉ từ Advanced Certificate Manager và chứng chỉ dự phòng. Tất cả chúng đều được ghi lại vào các nhật ký CT công khai theo thiết kế, vì một chứng chỉ không được ghi lại sẽ không được các trình duyệt lớn như Google Chrome và Apple Safari tin cậy. Vì vậy, chính sự minh bạch cho phép bạn giám sát việc cấp sai chứng chỉ cũng đồng thời hiển thị mọi chứng chỉ mà chúng tôi cấp cho bạn.
Và việc cấp chứng chỉ không phải là sự kiện chỉ diễn ra một lần. Các chứng chỉ có thời hạn ngắn và tự động gia hạn: một chứng chỉ Universal SSL đơn lẻ có thể gia hạn thường xuyên 60 ngày một lần, lên đến khoảng sáu lần một năm. Tần suất đó dự kiến sẽ còn tăng lên, khi CA/Browser Forum đã bỏ phiếu cắt giảm thời hạn chứng chỉ tối đa xuống còn 47 ngày vào năm 2029, làm tăng số lượng các đợt gia hạn định kỳ chảy qua các nhật ký đó. Mỗi lần gia hạn đều tạo ra một cảnh báo. Nhưng ở quy mô Cloudflare cấp chứng chỉ, một chứng chỉ thực sự đáng ngờ có thể trông giống hệt như một đợt gia hạn định kỳ, và cảnh báo quan trọng rất dễ bị bỏ lỡ.
Chúng tôi cũng nhận được phản hồi tương tự từ khách hàng. Trên diễn đàn cộng đồng của chúng tôi, một người dùng đã mô tả việc vô hiệu hóa tính năng này trên tất cả các trang web của họ vì họ "mệt mỏi khi thường xuyên bị spam bởi hàng tấn chứng chỉ gia hạn hoàn toàn bình thường", và nói thêm rằng "đến cuối cùng tôi thậm chí còn chẳng buồn đọc chúng nữa". Sự nhiễu loạn đó đến từ chính các chứng chỉ của Cloudflare.
Hôm nay, chúng tôi đang thay đổi điều đó. Giờ đây, Giám sát Minh bạch Chứng chỉ sẽ lọc bỏ các chứng chỉ mà Cloudflare đã thay mặt bạn cấp trước khi gửi cảnh báo. Các cảnh báo đến hộp thư của bạn sẽ là những cảnh báo xứng đáng với sự chú ý của bạn: một chứng chỉ mà bạn không mong đợi, không phải do Cloudflare cấp. Với bản sửa lỗi này, Giám sát Minh bạch Chứng chỉ hiện đã khả dụng rộng rãi.
Lọc bỏ các chứng chỉ do Cloudflare quản lý
Mục tiêu là xác định và loại bỏ các cảnh báo gây nhiễu đối với các đợt cấp và gia hạn chứng chỉ định kỳ do Cloudflare quản lý, đồng thời đảm bảo chúng tôi nắm bắt được tất cả các chứng chỉ bên ngoài được quản lý ngoài hệ thống của chúng tôi.
Tại sao trước đây chúng tôi không thể xác định và lọc bỏ những cảnh báo này?
Có hai hệ thống độc lập được xây dựng để phục vụ các sản phẩm riêng biệt: quản lý chứng chỉ, xử lý dữ liệu cấp chứng chỉ nội bộ và dịch vụ cảnh báo CT, chuyên phân tích dữ liệu từ các nhật ký CT công khai.
Hai luồng này xử lý cùng một chứng chỉ, nhưng không bao giờ cùng một lúc và không bao giờ có cùng thông tin. Khi luồng cảnh báo quyết định có gửi email cho bạn hay không, tất cả những gì nó có là dữ liệu lấy từ nhật ký. Nó không có tín hiệu nào từ luồng cấp chứng chỉ cho biết "dịch vụ đặt hàng vừa tạo cái này". Mối liên kết bị thiếu đó chính là vấn đề.
Vòng đời của một chứng chỉ là gì?
Như hình trên, việc cấp chứng chỉ diễn ra theo hai giai đoạn:
Do đó, dịch vụ cảnh báo nhìn thấy hai mục nhật ký cho một đơn hàng chứng chỉ: 1) chứng chỉ tiền khởi tạo (pre-certificate) và 2) chứng chỉ cuối cùng. Để tránh cảnh báo hai lần cho mỗi cặp, một định danh nội bộ gọi là stripped_fingerprint được lưu trữ cho mục đích khử trùng lặp. Dấu vân tay này là giá trị băm của TBSCertificate (chứng chỉ chờ ký) được mã hóa theo chuẩn DER (Distinguished Encoding Rules). Giá trị này nhất quán và duy nhất cho một cặp chứng chỉ tiền khởi tạo/chứng chỉ cuối cùng thuộc cùng một đơn hàng chứng chỉ. Vì vậy, đây là một định danh đã tồn tại và nó nằm hoàn toàn bên trong luồng cảnh báo.
Tại sao bản sửa lỗi hiển nhiên lại thất bại?
Lối tắt trực quan là sao chép stripped_fingerprint vào dịch vụ đặt hàng để bộ cảnh báo có thể tra cứu. Nhưng điều đó không hiệu quả vì dịch vụ đặt hàng không nhận được chứng chỉ tiền khởi tạo, nên nó không thể tạo ra giá trị này khi dịch vụ cảnh báo nhận được nó.
Vì vậy, ngay cả khi nó được sử dụng làm định danh, nó chỉ có thể được ghi lại sau khi chứng chỉ cuối cùng được dịch vụ đặt hàng tiếp nhận. Trong khoảng thời gian giữa các mục nhật ký chứng chỉ tiền khởi tạo và chứng chỉ cuối cùng, nếu dịch vụ cảnh báo tra cứu stripped_fingerprint(precert) trong cơ sở dữ liệu của dịch vụ đặt hàng, nó sẽ không tìm thấy thông tin nào khớp với định danh này để xác nhận rằng nó do chúng tôi cấp — và điều này lại dẫn đến một cảnh báo thừa.
Mặc dù dịch vụ đặt hàng chứng chỉ là hệ thống phù hợp để trả lời câu hỏi "Đây có phải của chúng tôi không?", nhưng khóa khớp (match key) dùng để xác định duy nhất thông tin này lại không thắng được cuộc đua về thời gian. Vì vậy, vấn đề đã được định hình lại. Câu hỏi không còn là lưu trữ dấu vân tay ở đâu, mà là đâu là định danh duy nhất có thể được duy trì từ khi tạo đơn hàng đến khi chứng chỉ cuối cùng được ghi lại.
Khóa nào là phù hợp?
Khóa phù hợp phải đáp ứng được các tiêu chí sau:
Khóa công khai (public key) là một định danh đáp ứng được tất cả các tiêu chí đó. Nó nằm bên trong một cấu trúc gọi là SubjectPublicKeyInfo (SPKI).
Tính nhất quán: Như sơ đồ trên cho thấy, SubjectPublicKeyInfo (SPKI) xuất hiện từ bước đầu tiên và giữ nguyên trong suốt quá trình CSR (Yêu cầu ký chứng chỉ), chứng chỉ tiền khởi tạo và chứng chỉ cuối cùng.
Tính duy nhất và an toàn: Cloudflare tạo một cặp khóa mới cho mỗi lần cấp, vì vậy khóa công khai thực sự là duy nhất. Vì chỉ Cloudflare có khóa riêng (private key), nên một chứng chỉ có SPKI khớp phải đến từ việc cấp của Cloudflare. Khả năng xảy ra va chạm là cực kỳ thấp và không ai bên ngoài có thể tạo ra yêu cầu ký hợp lệ nếu không có khóa riêng.
Vì vậy, định danh chúng tôi ghi lại là spki_sha256 — một giá trị băm SHA-256 của SPKI được mã hóa DER, một giá trị có độ dài cố định ngắn, dễ dàng lập chỉ mục. Dịch vụ đặt hàng tính toán nó trực tiếp từ CSR và ghi lại tại thời điểm tạo khóa, trước khi quá trình cấp bắt đầu.
Làm thế nào để cả hai luồng đồng ý về giá trị này?
Việc ghi lại khóa sớm giúp giải quyết vấn đề này trong quá trình đặt hàng chứng chỉ. Với điều đó, luồng cảnh báo thực hiện thêm một bước. Khi bộ cảnh báo nhìn thấy một mục nhật ký, nó tính toán lại spki_sha256 từ khóa công khai của chứng chỉ và tra cứu xem dịch vụ đặt hàng đã ghi giá trị này trong cơ sở dữ liệu của nó hay chưa.
Vì khóa giống hệt nhau trong chứng chỉ tiền khởi tạo và chứng chỉ cuối cùng, nên việc cái nào đến trước không còn quan trọng nữa.
Ba kết quả sau đây đều hướng tới việc giảm nhiễu:
Phần lớn công việc ở đây không phải là viết bản sửa lỗi; mà là hiểu đủ rõ cả hai luồng để thấy rằng khóa kết nối chúng là một trường dữ liệu mà chúng tôi đã mang theo suốt thời gian qua. Khi chúng tôi chọn được định danh sớm và được chia sẻ, phần còn lại chỉ là công việc sổ sách.
Cảnh báo CT chỉ nên kích hoạt đối với các đợt cấp mà chúng tôi không thể giải trình. Với thay đổi này, nó đã làm được điều đó.
Các cảnh báo hiện dễ xem xét hơn
Các email cập nhật xác định tên máy chủ bị ảnh hưởng trong dòng tiêu đề, bao gồm chi tiết chứng chỉ trong nội dung tin nhắn và liên kết đến chứng chỉ trong bảng điều khiển Cloudflare, để bạn có thể xem xét và thực hiện hành động khi cần.
Tiếp theo là gì
Chúng tôi dự định đưa Giám sát Minh bạch Chứng chỉ vào Cloudflare Notifications. Điều này sẽ cho phép các nhóm định tuyến cảnh báo CT đến các webhook, PagerDuty hoặc các địa chỉ email bổ sung, giống như cách họ quản lý các cảnh báo khác của Cloudflare, thay vì chỉ dựa vào kênh email như hiện nay.
Hãy dùng thử
Bạn đã sử dụng Giám sát Minh bạch Chứng chỉ? Bạn không cần phải làm gì cả. Tính năng lọc đã được kích hoạt. Kể từ hôm nay, bạn sẽ chỉ nhận được thông báo về các chứng chỉ được cấp bên ngoài các hệ thống tự động của Cloudflare.
Bạn chưa sử dụng tính năng này? Trong bảng điều khiển Cloudflare, hãy đi tới SSL/TLS → Edge Certificates → Certificate Transparency Monitoring và bật nó lên. Tính năng này khả dụng trên mọi gói dịch vụ mà không mất thêm chi phí, với các cài đặt thống nhất trên các cấp gói, vì vậy bạn có thể quản lý người nhận cảnh báo trong một giao diện nhất quán.
Nếu bạn có suy nghĩ về cách Giám sát Minh bạch Chứng chỉ nên phát triển, hãy cho chúng tôi biết thông qua nhóm quản lý tài khoản của bạn hoặc Cộng đồng Cloudflare. Ý kiến đó sẽ định hình các tùy chọn tùy chỉnh mà chúng tôi xây dựng tiếp theo.
Bài viết được AI dịch và tổng hợp tự động từ Cloudflare Blog. Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.