Chỉ một CSR không phải là đăng ký: VPN CA phải kiểm tra những gì

Một yêu cầu ký chứng chỉ mang khóa công khai và subject được yêu cầu, được ký bằng khóa riêng tư tương ứng. Chữ ký đó chứng minh người yêu cầu có khóa. Nó không chứng minh người yêu cầu có quyền với tên, thiết bị hoặc vai trò VPN được yêu cầu, và coi yêu cầu như thể nó chứng minh điều đó chính là cách một phiếu yêu cầu hỗ trợ trở thành việc cấp quyền truy cập.

Hai mô hình đăng ký đáng được so sánh theo những gì chúng ràng buộc, không phải theo giao thức chúng nói.

Yêu cầu khẳng định một cái tên, không chứng minh nó

Hãy đọc yêu cầu theo những gì nó thực sự chứa: khóa công khai, subject do người yêu cầu chọn và chữ ký tự thân trên cả hai. Không có gì trong cấu trúc đó tham chiếu đến kiểm kê, danh mục tài khoản hay quy trình phê duyệt của bạn. Một subject như cn=finance-laptop là chuỗi do ai đó gõ vào. Cho đến khi quy trình cấp kiểm tra chuỗi đó với một bản ghi mà nó tin cậy, chứng chỉ chỉ là một khẳng định kèm chữ ký. Sự khác biệt đó chính là toàn bộ lý do tồn tại của quy trình đăng ký.

Hệ quả có ý nghĩa vận hành. Cơ quan chứng thực không bao giờ cần khóa riêng tư của khách hàng để cấp chứng chỉ, và một quy trình yêu cầu khóa đó đã nhầm lẫn việc ký với việc lưu giữ khóa. Giữ việc tạo khóa ở điểm cuối và chỉ gửi nửa công khai.

So sánh các mô hình theo những gì chúng ràng buộc

Ký thủ công ràng buộc những gì người vận hành nhớ kiểm tra. Dịch vụ đăng ký tự động ràng buộc một yêu cầu đã xác thực với một quyết định mà dịch vụ có thể thực thi, và RFC 7030 mô tả một thiết kế như vậy trong đó khách hàng xác thực trước khi chứng chỉ được trả về. Khác biệt còn sống sót qua kiểm toán không phải là tự động hóa; mà là việc kiểm tra danh tính diễn ra bên trong đường cấp hay bên cạnh nó.

Cả hai mô hình vẫn phải trả lời ba câu hỏi như nhau. Ai đang yêu cầu, trên thiết bị hoặc vai trò nào, và trong bao lâu. Một hệ thống phiếu ghi lại câu trả lời đang làm công việc thật; một hàng đợi nơi ai đó nhìn chằm chằm vào một tên chung thì không, dù chứng chỉ sau đó có được định dạng cẩn thận đến đâu.

Chọn mô hình theo số lượng đăng ký bạn dự kiến và theo tốc độ thay thế thiết bị. Một vài máy chủ mỗi năm có thể chịu được việc rà soát thủ công với danh sách kiểm tra bằng văn bản. Một đội máy tính xách tay thì không.

Ghi lại vòng đời ngay từ lần cấp đầu tiên

Lưu mã định danh chứng chỉ, chủ sở hữu, mục đích sử dụng, ngày hết hạn và đường dẫn gỡ bỏ ngay tại thời điểm cấp, không phải ở sự cố đầu tiên. Mục đích sử dụng phải nằm trong chính chứng chỉ thông qua việc sử dụng khóa mở rộng, và bản ghi phải khớp với điều đó. Chứng chỉ được tạo cho xác thực khách hàng không được không thể phân biệt với chứng chỉ cho máy chủ.

Hãy lên kế hoạch gia hạn và thu hồi thiết bị bị mất trước khi cấp hồ sơ thứ mười. Một chứng chỉ dùng chung trong cả phòng ban biến việc gỡ bỏ có mục tiêu thành gián đoạn, và việc xem xét lại quyết định đó bây giờ rẻ hơn nhiều so với trong một sự cố thứ Sáu.

Kiểm tra chứng chỉ đã cấp, rồi đến quyền truy cập

Sau khi đăng ký, hãy kiểm tra những gì đã được cấp và xác nhận rằng nó chuỗi đến cơ quan bạn mong đợi. Hai lệnh bao quát các lỗi phổ biến: chứng chỉ dùng sai mục đích và một chuỗi chỉ hoạt động vì máy khách được cấu hình để bỏ qua việc xác thực.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

Sau đó hãy kiểm tra quyền truy cập chứ không phải sản phẩm. Chứng chỉ xác lập danh tính, và chính sách vẫn quyết định danh tính đó có thể chạm tới những dịch vụ nào. Hãy kiểm tra cả hai, vì một sản phẩm đúng nhưng đi kèm chính sách quá rộng vẫn không qua được rà soát. Xác nhận rằng máy khách xác thực và chỉ nhận được các tuyến hoặc tài nguyên dự kiến. Ghi lại những gì bạn quan sát, không phải những gì hồ sơ lẽ ra phải làm.

Một hồ sơ hoạt động vì lý do sai, chẳng hạn như tên chung trùng khớp và không có kiểm tra danh tính, sẽ tiếp tục hoạt động sau khi biện pháp kiểm soát mà bạn tưởng có bị gỡ bỏ.