Công cụ tạo CSR

Vì một khóa riêng đã đến máy chủ của người khác thì đúng với định nghĩa của chính ngành này về khóa bị lộ — bất kể máy chủ đó sau đó làm gì với nó.

Baseline Requirements của CA/Browser Forum định nghĩa điều đó không chừa chỗ cho tranh cãi: "A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it." Không cần bị lạm dụng. Chỉ cần đến nơi là đủ.

Đó không phải chuyện lý thuyết. Năm 2020, DigiCert phát hiện 337 khóa riêng mà khách hàng đã dán kèm với yêu cầu của họ, thu hồi mọi chứng chỉ liên quan và công bố việc này: "by sending the private key to DigiCert along with the CSR, the customer has compromised the private key", và nói thêm rằng "the only part of a CSR we use is the public key". Một công cụ tạo khóa trên máy chủ của nó rồi đưa bạn một bản sao thì, theo định nghĩa đó, đã làm lộ khóa rồi. Trang này không thể làm vậy: crypto.subtle.generateKey chạy trong trình duyệt của bạn, bên trong một khung cách ly không được phép kết nối đi đâu, và trang bao quanh nó chỉ thấy khóa công khai.

ECDSA P-256 cho mọi thứ mới: nó mạnh ngang một khóa RSA 3072 bit, nhỏ hơn nhiều, và được các quy tắc mà mọi tổ chức cấp chứng chỉ công khai tuân theo cho phép. RSA 2048 khi một thiết bị cũ phải đọc được khóa.

NIST xếp P-256 và RSA-3072 ở cùng mức an toàn 128 bit, và hoàn toàn không gán mức an toàn riêng nào cho RSA-4096 — bậc kế tiếp trong bảng của họ là 7680 bit. Vì vậy 4096 khiến mỗi khách truy cập tốn thêm công sức bắt tay mà không có lợi ích nào được ghi nhận. P-384 là bậc 192 bit, và Baseline Requirements cũng cho phép P-521, nhưng Let's Encrypt từ chối P-521: một yêu cầu có thể hoàn toàn hợp lệ mà vẫn thất bại ở CA bạn định dùng.

Ed25519 được cung cấp ở đây vì nó rất tốt cho SSH, cho việc ký và cho một CA riêng — nhưng không tổ chức cấp chứng chỉ công khai nào cấp chứng chỉ TLS cho nó. Quy tắc liệt kê RSA và ba đường cong NIST rồi nói "no other algorithms or key sizes are permitted". Điều tương tự áp dụng cho ML-DSA hậu lượng tử: đề xuất bỏ phiếu có thể cho phép nó trong TLS công khai đã bị đóng mà không được hợp nhất vào tháng 10 năm 2026. Công cụ nói điều đó ngay bên cạnh từng lựa chọn, thay vì để bạn phát hiện qua một email từ chối.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes -keyout example.com.key -out example.com.csr tạo khóa và yêu cầu chỉ trong một bước.

Công cụ viết lệnh cho bất cứ thứ gì bạn đã điền, gồm cả các tên thay thế và mọi phần mở rộng, và các bài kiểm thử của chúng tôi chạy nó qua OpenSSL để xác nhận nó tạo cùng chủ thể và cùng các phần mở rộng với trang. Thêm -subj "/CN=example.com" để bỏ qua các câu hỏi, -addext "subjectAltName=DNS:example.com,DNS:www.example.com" cho các tên, và -utf8 để một tên có dấu không bị hỏng. -nodes để khóa không được mã hóa: OpenSSL 3 thích cách viết mới hơn là -noenc nhưng vẫn nhận -nodes, cũng là cách viết duy nhất mà LibreSSL tích hợp trong macOS hiểu. LibreSSL đó hoàn toàn không tạo được khóa Ed25519; hãy dùng OpenSSL 1.1.1 trở lên cho loại đó.

Để kiểm tra những gì bạn đã tạo: openssl req -in example.com.csr -text -verify -noout in mọi trường và xác minh chữ ký tự ký, dừng lại trước khi in bất cứ thứ gì nếu chữ ký sai. Để xác nhận khóa thuộc về yêu cầu, hãy so sánh openssl req -in example.com.csr -pubkey -noout với openssl pkey -in example.com.key -pubout. Không tiêu chuẩn nào gán phần mở rộng tên tệp cho một CSR, nên .csr, .pem, .req và .txt đều đúng.