Thách thức trong việc vận hành website với chứng chỉ bị thu hồi hoặc hết hạn

Hầu hết các quản trị viên web luôn mong muốn chứng chỉ HTTPS của mình hoạt động trơn tru và hợp lệ. Tuy nhiên, với tư cách là một Ủy quyền Chứng chỉ (Certificate Authority - CA), Let's Encrypt lại đối mặt với một vấn đề ngược lại: chúng tôi cần đảm bảo rằng một số trang web thử nghiệm của mình phải có chứng chỉ bị thu hồi hoặc đã hết hạn. Đây là một yêu cầu bắt buộc đối với các CA công khai, nhưng việc triển khai nó chính xác lại phức tạp hơn nhiều người nghĩ.

Trước đây, chúng tôi sử dụng kết hợp giữa Certbot, Nginx và các script shell để xử lý việc này. Tuy nhiên, các script shell ngày càng trở nên phức tạp và khó bảo trì. Do đó, chúng tôi đã quyết định viết một chương trình bằng ngôn ngữ Go, được tùy chỉnh riêng để đáp ứng các nhu cầu đặc thù của trang web chứng chỉ thử nghiệm.

Các loại trang web thử nghiệm

Chúng tôi cần lưu trữ ba loại trang web cho mỗi chứng chỉ gốc:

• Một trang web có chứng chỉ hợp lệ (như bất kỳ trang web bình thường nào).
• Một trang web có chứng chỉ hết hạn (đã vượt qua ngày hiệu lực).
• Một trang web có chứng chỉ bị thu hồi (nhưng chưa hết hạn).

Việc thiết lập trang web có chứng chỉ hợp lệ rất đơn giản, đây là trường hợp tiêu chuẩn. Tương tự, chứng chỉ hết hạn cũng khá dễ xử lý: bạn chỉ cần cấp một chứng chỉ, chờ đến khi nó hết hạn và sau đó sử dụng nó vĩnh viễn. Tuy nhiên, loại chứng chỉ bị thu hồi lại là nơi dễ xảy ra sai sót nhất. Bạn có thể quên thu hồi chứng chỉ và phục vụ một chứng chỉ hoàn toàn hợp lệ, hoặc để chứng chỉ bị thu hồi của bạn hết hạn. Đảm bảo trang web phục vụ một chứng chỉ đã bị thu hồi nhưng chưa hết hạn là điều mà các công cụ có sẵn trên thị trường không hỗ trợ.

Các thành phần để xây dựng giải pháp

Để triển khai chương trình này, chúng tôi cần kết hợp một số thành phần quan trọng. Đầu tiên, chúng tôi sử dụng thư viện Lego trong Go để yêu cầu chứng chỉ thông qua giao thức ACME. Quá trình xác thực tên miền sử dụng phương thức TLS-ALPN-01 vì nó không yêu cầu cấu hình phức tạp ngoài việc exposing webserver ra internet.

Để có chứng chỉ bị thu hồi, chúng tôi yêu cầu cấp một chứng chỉ rồi sau đó thu hồi nó ngay lập tức. Sau đó, chúng tôi cần kiểm tra xem chứng chỉ đó đã xuất hiện trong Danh sách Thu hồi Chứng chỉ (CRL) hay chưa bằng cách thăm dò URL HTTP có trong chứng chỉ.

Let's Encrypt triển khai tiêu chuẩn ACME, vốn định nghĩa cách các ứng dụng khách lấy chứng chỉ. Chúng tôi tin rằng các ứng dụng khách ACME tích hợp vào webserver thường là cách tốt nhất để lấy chứng chỉ, giúp tự động xử lý các thử thách, quản lý và tải lại chứng chỉ, từ đó giảm thiểu công việc và sự cố.

Quản lý thời gian và trạng thái

Một thách thức lớn khác là quản lý thời gian. Chứng chỉ hợp lệ có thể sử dụng ngay lập tức, nhưng chứng chỉ bị thu hồi và hết hạn thì không. Chúng tôi phải đợi ít nhất 24 giờ cho chứng chỉ bị thu hồi để đảm bảo các bộ nhớ đệm CRL hoặc cơ sở hạ tầng CRL dựa trên đẩy có đủ thời gian xử lý. Đối với chứng chỉ hết hạn, thời gian chờ thậm chí còn dài hơn.

Chương trình của chúng tôi lưu trữ một chứng chỉ "next" thay vì ghi đè ngay lập tức chứng chỉ hiện tại, chỉ thay thế khi chứng chỉ mới đã ở trạng thái sẵn sàng. Sau khi chương trình quyết định chứng chỉ đã sẵn sàng, nó sẽ thay thế chứng chỉ hiện tại và chuyển nó cho webserver. Các công cụ ACME thông thường không hỗ trợ điều này vì chúng thường bắt đầu sử dụng chứng chỉ ngay khi nhận được.

Cuối cùng, chúng tôi sử dụng webserver tích hợp sẵn của Go, vốn có stack TLS và HTTP rất mạnh mẽ. Máy chủ TLS của Go sử dụng hàm callback GetCertificate để quyết định chứng chỉ nào sẽ được sử dụng cho từng kết nối mới. Tất cả chứng chỉ được lưu trong bộ nhớ và chúng tôi chọn đúng chứng chỉ để phục vụ dựa trên SNI (Server Name Indication) của yêu cầu.

Trải nghiệm người dùng và "Trứng phục sinh"

Nếu bạn truy cập một trong các trang web bị thu hồi của chúng tôi, bạn có thể không thấy thông báo lỗi ngay lập tức vì cách trình duyệt kiểm tra thu hồi rất khác nhau. Hiện tại, Firefox với công nghệ CRLite và dự án upki của Ubuntu đang dẫn đầu về hiệu quả và độ tin cậy trong việc này. Chúng tôi hy vọng các trình duyệt và hệ điều hành khác sẽ sớm làm theo.

Nội dung thực tế của trang web không quá quan trọng, nhưng vì đây là trang web dùng để kiểm thử ứng dụng khách, nên có nhiều loại kết nối khác nhau ngoài trình duyệt. Là một "trứng phục sinh" nhỏ, chúng tôi đã thêm phiên bản văn bản thuần túy (plain text) của trang web với logo ASCII art nếu ứng dụng HTTP của bạn không bao gồm text/html trong header Accept. Bạn cũng có thể truyền tham số ?txt hoặc ?html để yêu cầu phiên bản cụ thể.

Mã nguồn của dự án này đã được mã nguồn mở và có sẵn tại GitHub. Các CA khác cần vận hành trang web thử nghiệm tương tự đều hoan nghênh sử dụng. Hiện tại, Let's Encrypt có bốn chứng chỉ gốc, mỗi chứng chỉ đều đi kèm các liên kết đến trang thử nghiệm hợp lệ, hết hạn và bị thu hồi.