Công cụ giải mã CSR

Dán một yêu cầu ký chứng chỉ để đọc mọi trường trong đó: chủ thể, khóa, từng tên thay thế và từng phần mở rộng. Trang còn đối chiếu yêu cầu với các quy tắc mà CA công khai áp dụng, và cho bạn biết khóa riêng của mình có khớp với nó không. Chứng chỉ SSL cũng giải mã được tại đây.

Giải mã ngay trong trình duyệt bằng Web Crypto · không tải gì lên, không lưu gì cả · CA/Browser Forum Baseline Requirements v2.3.1

Mọi thứ trên trang này diễn ra trong trình duyệt của bạn. Hãy mở bảng điều khiển mạng và quan sát: không yêu cầu nào mang dữ liệu của bạn đi.

CSR là gì?

Yêu cầu ký chứng chỉ (CSR) là một tệp nhỏ đã được ký, dùng để xin một tổ chức cấp chứng chỉ cấp chứng chỉ. Nó mang khóa công khai của bạn, các tên bạn muốn có trên chứng chỉ, và một chữ ký tạo bằng khóa riêng của bạn.

Định dạng là PKCS#10, được ghi trong RFC 2986. Phần được ký chỉ chứa bốn thứ: số phiên bản, tên chủ thể, SubjectPublicKeyInfo chứa khóa công khai của bạn, và một tập thuộc tính. Toàn bộ phần đó sau đó được ký bằng khóa riêng đi cùng với khóa công khai nằm bên trong, nên CSR là tự ký. Chữ ký đó là bằng chứng sở hữu: ai cũng đọc được khóa công khai của bạn, nhưng chỉ người giữ khóa riêng mới ký được một yêu cầu mà chữ ký khớp với nó.

Khóa riêng của bạn không nằm trong tệp và không bao giờ nên nằm trong đó. CSR an toàn để gửi qua email, dán vào biểu mẫu web của CA, và giải mã tại đây — đó là lý do trang này làm được mọi việc ngay trong trình duyệt của bạn mà không gửi gì đi đâu cả.

Một yêu cầu, từng byte mộtRFC 2986 · PKCS#10

Toàn bộ tệp

  • Lớp bọc4 byte
  • Phần được ký469 byte
  • Thuật toán chữ ký nào15 byte
  • Bản thân chữ ký261 byte

Bên trong phần được ký

  1. Phiên bản3 byteLuôn bằng không: phiên bản duy nhất mà định dạng định nghĩa
  2. Tên chủ thể108 byteTên phân biệt bạn đã gõ vào biểu mẫu
  3. Khóa công khai của bạn294 byteThuật toán, kích thước và khóa — trường duy nhất mà tổ chức cấp chứng chỉ chắc chắn sẽ dùng
  4. Thuộc tính60 byteNơi các tên thay thế bạn xin được chuyển đi

Khóa riêng của bạnký phần bên trênBằng chứng rằng bạn giữ khóa riêng tương ứng · Chữ ký chỉ bao phần đó, không bao toàn bộ tệp

Yêu cầu mẫu mà trang này cung cấp, dung lượng 749 byte. Bốn thứ nằm trong phần được ký; khóa riêng khớp với khóa công khai bên trong ký đúng phần đó, và thứ ra được là 261 byte cuối cùng.
Kết quả giải mã CSR: một yêu cầu ký chứng chỉ đã giải mã, gồm chủ thể, khóa, tên thay thế và các phát hiện theo quy tắc CAKết quả giải mã CSR: một yêu cầu ký chứng chỉ đã giải mã, gồm chủ thể, khóa, tên thay thế và các phát hiện theo quy tắc CADán hoặc thảMột CSR, một chứng chỉ hoặc một khóa công khai — PEM, base64, bản dump hex hoặc một tệp. Nhiều mục cùng lúc cũng được.Kết luậnCA công khai sẽ làm gì với yêu cầu này: cấp, thay đổi hoặc từ chối, kèm lý do cho từng trường hợp.Các tênMọi tên mà chứng chỉ sẽ bao gồm, với tên chung được đối chiếu với chúng.Khóa và chữ kýThuật toán, kích thước, đường cong và số mũ, cùng việc chữ ký của chính yêu cầu có hợp lệ hay không.So khớp khóaThêm khóa riêng hoặc chứng chỉ đã được cấp để xem nó có thuộc về yêu cầu này không. Cả hai đều không rời khỏi trình duyệt của bạn.
Một yêu cầu ký chứng chỉ được tháo ra từng phần: kết luận, các tên nó xin, khóa phía sau và một chỗ để so khớp khóa của chính bạn. Chọn một số để xem từng phần hiển thị gì.

Cách kiểm tra CSR trước khi gửi

Có ba điều đáng kiểm tra: các tên có đúng là những tên bạn định dùng không, chữ ký có hợp lệ không, và không có gì trong đó vi phạm quy tắc mà CA của bạn áp dụng.

Dán yêu cầu vào phía trên. Trang đọc chủ thể từng thuộc tính một, liệt kê mọi tên thay thế của chủ thể (SAN), cho thấy thuật toán và kích thước của khóa, rồi kiểm tra chữ ký của chính yêu cầu. Một yêu cầu có chữ ký không hợp lệ đã bị chỉnh sửa, cắt cụt hoặc hỏng kể từ khi được tạo — hãy tạo lại thay vì gửi đi.

Sau đó đến các quy tắc. Tổ chức cấp chứng chỉ áp dụng Baseline Requirements của CA/Browser Forum, và một yêu cầu vi phạm một trong số đó sẽ bị từ chối hoặc âm thầm bị đổi. Các phát hiện trên trang này được đánh dấu Phải sửa khi CA không thể cấp thứ bạn xin, Sẽ bị đổi khi CA sẽ cấp nhưng loại bỏ hoặc thay đổi một trường, và Lưu ý khi không có gì sai nhưng có điều đáng xem.

Ba lần kiểm tra, theo thứ tự chạyCA/Browser Forum TLS BR 2.3.1
  1. Các tênMọi tên mà chứng chỉ sẽ bao gồm, và tên chung có nằm trong số đó không
  2. Chữ kýĐược xác minh bằng mật mã của chính trình duyệt của bạn
  3. Quy tắc của tổ chức cấp chứng chỉÁp dụng từng quy tắc một, mỗi quy tắc kèm tài liệu nó đến từ đâu
  • Gửi điKhông có gì trong yêu cầu vi phạm quy tắc
  • Sẽ bị từ chốiTệp không có lỗi; thứ nó xin thì không được phép
  • Tạo lạiChữ ký không hợp lệ nghĩa là tệp đã bị chỉnh sửa, cắt cụt hoặc sao chép hỏng sau khi được tạo
Hai lần kiểm tra đầu nói về chính tệp và lần thứ ba nói về điều tổ chức cấp chứng chỉ cho phép. Một yêu cầu có thể đạt cả hai lần đầu mà vẫn bị từ chối.

Trong CSR có gì — và CA thực sự dùng gì

Trong mọi thứ của một CSR, CA công khai chỉ dùng chắc chắn một trường: khóa công khai. Phần lớn phần còn lại, CA tự xác thực, ghi đè hoặc bị cấm sao chép.

DigiCert nói thẳng trong tài liệu của chính mình: "DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored." Trên chứng chỉ OV hoặc EV, CA phải tự xác thực tổ chức, địa phương và quốc gia trước khi đưa vào; những gì bạn gõ không được tin ngay. Ngày hiệu lực không bao giờ lấy từ yêu cầu: chúng theo lịch trình của Baseline Requirements.

Hai trường chủ thể không chỉ bị bỏ qua mà còn bị cấm. organizationalUnitName (OU) không được xuất hiện trong chứng chỉ TLS công khai — theo ballot SC047 của CA/Browser Forum, không chứng chỉ nào được cấp từ ngày 1 tháng 9 năm 2022 được mang nó — và emailAddress hoàn toàn không được phép trong chứng chỉ xác thực tên miền. Tên chung được phép nhưng không khuyến khích, và nếu có thì nó phải lặp lại chính xác một trong các tên thay thế. Quy tắc cuối cùng đó là lý do trang này đánh dấu tên chung không có trong danh sách SAN.

Tổ chức cấp chứng chỉ làm gì với từng trườngCA/Browser Forum TLS BR 2.3.1
Trong yêu cầu của bạnNó trở thành gìVì sao
Khóa công khaiSubjectPublicKeyInfoDùng đúng như bạn gửiThứ duy nhất mà tổ chức cấp chứng chỉ chắc chắn lấy từ bạn
Các tên thay thếsubjectAltName2.5.29.17Dùng đúng như bạn gửiCA xác nhận bạn kiểm soát từng tên trước khi ghi bất kỳ tên nào
Tên chungCN2.5.4.3Được xác thực, rồi CA tự ghiKhông khuyến khích; nếu có thì phải lặp lại chính xác một trong các tên thay thế
Tổ chức, địa phương, tỉnh/bangO, L, ST2.5.4.10Được xác thực, rồi CA tự ghiTrên chứng chỉ xác thực tổ chức, các trường này lấy từ hồ sơ đã được CA xác thực, không phải từ những gì bạn gõ
Quốc giaC2.5.4.6Được xác thực, rồi CA tự ghiCó thể xuất hiện, bất kể mức xác thực
Đơn vị tổ chứcOU2.5.4.11Hoàn toàn không được phépBị cấm trong chứng chỉ công khai từ 1 tháng 9, 2022
Địa chỉ emailemailAddress1.2.840.113549.1.9.1Hoàn toàn không được phépKhông được phép trong chứng chỉ xác thực tên miền
Có hiệu lực từ, đếnnotBefore, notAfterKhông bao giờ lấy từ yêu cầuDo lịch trình mà tổ chức cấp chứng chỉ tuân theo đặt ra, không bao giờ do yêu cầu của bạn

“DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.”

DigiCert, tài liệu của chính họ
Những trường người ta lo lắng nhất, và giá trị thực của từng trường. Khóa và các tên của bạn được giữ lại; đơn vị tổ chức không thể xuất hiện, và địa chỉ email cũng không thể có trên chứng chỉ xác thực tên miền, bất kể bạn gõ gì; và ngày tháng chưa bao giờ do bạn đặt.

Vì sao CA từ chối một CSR

Gần như mọi lần từ chối quy về một tên mà CA không được phép chứng nhận, một wildcard quá rộng, một địa chỉ IP dành riêng, một khóa quá nhỏ, một hàm băm chữ ký quá cũ, hoặc một yêu cầu có chữ ký không hợp lệ.

Tổ chức cấp chứng chỉ không được cấp cho một tên nội bộ — tên mà "does not end with a Top-Level Domain registered in IANA's Root Zone Database". Điều đó loại server.local, intranet, tên chỉ có một nhãn không có dấu chấm nào, và mọi đuôi tự bịa. Nhãn chỉ được gồm chữ cái, chữ số và dấu gạch ngang, nên dấu gạch dưới trong tên máy chủ bị từ chối, và tên không được viết với dấu chấm ở cuối. Wildcard chỉ được thay cho toàn bộ nhãn ngoài cùng bên trái, và không bao giờ cho một public suffix: *.example.com thì được, *.co.uk thì không. Địa chỉ IP có thể xuất hiện, nhưng không được là địa chỉ dành riêng — không có 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 hay fc00::/7.

Về khóa, Baseline Requirements rất chính xác: modulus RSA tối thiểu 2048 bit và chia hết cho 8, hoặc một điểm trên P-256, P-384 hay P-521, và "no other algorithms or key sizes are permitted". CA cũng phải từ chối khóa mà nó có thể phân tích thừa số, kể cả khóa "which can be factored within 100 rounds using Fermat's factorization method" — trang này chạy phép thử đó trên khóa trong yêu cầu của bạn. Và dù hàm băm chữ ký của CSR không phải của chứng chỉ, Let's Encrypt đã ngừng nhận chữ ký tự ký SHA-1 từ năm 2022, nên một công cụ cũ vẫn ký bằng SHA-1 sẽ bị trả yêu cầu lại.

Các tên mà tổ chức cấp chứng chỉ sẽ không chứng nhậnCA/Browser Forum TLS BR 2.3.1
  • server.local
    Một tên nội bộNó không kết thúc bằng tên miền cấp cao nhất có trong vùng gốc công khai, nên không ai chứng minh được nó là của bạn
    Bị từ chối
  • intranet
    Tên chỉ có một nhãnMột tên không có dấu chấm nào thuộc cùng định nghĩa đó
    Bị từ chối
  • my_host.example.com
    Một dấu gạch dướiMột nhãn chỉ được gồm chữ cái, chữ số và dấu gạch ngang, không gì khác
    Bị từ chối
  • *.co.uk
    Một wildcard trên cả một nhà đăng kýWildcard có thể thay cho nhãn ngoài cùng bên trái, không bao giờ cho một public suffix
    Bị từ chối
  • 192.168.1.10
    Một địa chỉ dành riêngĐịa chỉ công khai có thể được chứng nhận; địa chỉ thuộc dải riêng tư hoặc dải đặc biệt thì không bao giờ
    Bị từ chối
  • example.com.
    Dấu chấm ở cuốiNhãn gốc rỗng không được viết ra
    Bị từ chối
Sáu tên, mỗi tên vi phạm một quy tắc khác nhau — và từng cái đều là lý do bị từ chối mà bạn có thể thấy trước khi gửi yêu cầu.

Làm sao biết khóa riêng của tôi khớp với CSR?

Tệp khóa riêng đã mang sẵn khóa công khai của nó, nên việc so khớp là so sánh hai khóa công khai — không cần bí mật nào và không phải gửi gì đi đâu.

Mở So khớp với một khóa hoặc chứng chỉ phía trên và thêm khóa bên cạnh yêu cầu. Trang chỉ đọc phần công khai ra khỏi tệp — khóa PKCS#8, PKCS#1 và SEC1 đều được hiểu — so sánh với khóa trong yêu cầu rồi trả lời. Không có gì được tải lên, không có gì được giữ lại, và khóa bị xóa khi bạn rời khỏi ô. Phép kiểm tra tương tự dùng được giữa một yêu cầu và chứng chỉ mà CA trả về, giúp bắt lỗi "the certificate and the private key do not match" trước khi máy chủ không chịu khởi động.

Nếu bạn không muốn dán khóa vào bất kỳ trang web nào, câu trả lời tương tự chỉ cần hai lệnh trên máy của bạn. openssl req -in request.csr -pubkey -noout in khóa công khai từ yêu cầu và openssl pkey -in private.key -pubout in nó từ khóa: kết quả giống hệt nghĩa là chúng khớp nhau. Dạng -modulus cũ chỉ dùng được cho khóa RSA; -pubkey dùng được cho mọi loại khóa.

Hai tệp, một phép so sánhRFC 2986 · OpenSSL manual
Trình duyệt của bạn
  • Tệp khóa riêngTệp bạn không bao giờ được gửi đi đâuPhần công khai của nó được đọc ra
  • Yêu cầuTệp bạn gửi cho tổ chức cấp chứng chỉNó đã mang sẵn khóa công khai

Đây có phải cùng một khóa không?

  • Khớp nhauChứng chỉ trả về sẽ cài được với khóa này
  • Không khớp nhauĐây là sự không khớp mà máy chủ web báo khi nó không chịu khởi động

Không gì vượt qua đường này · Phép so sánh chạy được khi tắt mạngBất kỳ nơi nào khác

Hoặc làm trên máy của bạnopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutKết quả giống hệt nghĩa là chúng khớp nhau
Tệp khóa riêng đã mang sẵn khóa công khai của nó, nên câu hỏi được giải quyết bằng cách so sánh hai khóa công khai. Không bí mật nào phải di chuyển để làm việc đó, và cũng không có gì di chuyển.

CSR, chứng chỉ, khóa riêng: khác nhau thế nào?

Khóa riêng là bí mật. CSR là một yêu cầu chứng minh bạn giữ nó. Chứng chỉ là câu trả lời đã ký của CA, và là tệp duy nhất trong ba tệp được thiết kế để công khai.

Ba tệp này thường nằm trong cùng một thư mục với những cái tên dễ nhầm lẫn. Khóa riêng bắt đầu bằng -----BEGIN PRIVATE KEY----- hoặc -----BEGIN RSA PRIVATE KEY----- và không bao giờ được gửi cho ai, kể cả tổ chức cấp chứng chỉ. Yêu cầu ký chứng chỉ bắt đầu bằng -----BEGIN CERTIFICATE REQUEST-----, được ký bằng khóa đó, và an toàn để gửi. Chứng chỉ bắt đầu bằng -----BEGIN CERTIFICATE-----, được CA ký, và dù sao cũng được gửi cho mọi khách truy cập website của bạn.

Khi chứng chỉ đã được cấp, yêu cầu không còn tác dụng: nó không cần để cài đặt, gia hạn hay thu hồi bất cứ thứ gì. Khóa mới là thứ bạn phải giữ, và giữ an toàn. Hãy dán một trong ba tệp phía trên và trang này sẽ cho bạn biết đó là tệp nào.

Ba tệp, một thư mục, những cái tên dễ nhầmRFC 7468
  • Khóa riêngBí mật

    Dòng đầu tiên của nó-----BEGIN PRIVATE KEY-----Cũng được dùng rộng rãi-----BEGIN RSA PRIVATE KEY-----

    Được ký bởi
    Không ai — chính nó là thứ thực hiện việc ký
    Ai được thấy nó
    Bạn, và không ai khác
    Dùng để làm gì
    Chứng minh máy chủ này đúng là nơi chứng chỉ được cấp cho
  • Yêu cầu ký chứng chỉCông khai

    Dòng đầu tiên của nó-----BEGIN CERTIFICATE REQUEST-----Cũng được dùng rộng rãi-----BEGIN NEW CERTIFICATE REQUEST-----

    Được ký bởi
    Chính nó, bằng khóa riêng
    Ai được thấy nó
    Bạn và tổ chức cấp chứng chỉ
    Dùng để làm gì
    Xin một chứng chỉ, và chứng minh bạn giữ khóa mà nó dành cho
  • Chứng chỉCông khai

    Dòng đầu tiên của nó-----BEGIN CERTIFICATE-----

    Được ký bởi
    Tổ chức cấp chứng chỉ
    Ai được thấy nó
    Mọi khách truy cập website của bạn
    Dùng để làm gì
    Cho trình duyệt biết khóa này thuộc về những tên này

.csr.pem.req.txtKhông tiêu chuẩn nào gán phần mở rộng tên tệp cho một yêu cầu; tất cả những cái này đều đang được dùng, và trang này đọc nội dung chứ không đọc tên

Chỉ tệp đầu tiên trong ba tệp là bí mật. Tệp cuối dù sao cũng được gửi cho mọi khách truy cập, và tệp giữa không còn tác dụng ngay khi chứng chỉ đến.

Giải mã CSR trực tuyến có an toàn không?

CSR không chứa bí mật nào, nên giải mã nó ở đâu cũng vô hại. Khóa riêng thì khác, và đó là tệp mà người ta hay nhầm với nó.

Mọi thứ trên trang này chạy trong trình duyệt của bạn. Yêu cầu được phân tích bằng mã tải về cùng với trang, chữ ký được kiểm tra bằng Web Crypto của chính trình duyệt, và không có yêu cầu nào gửi đến máy chủ nào kèm dữ liệu của bạn — bạn có thể theo dõi bảng điều khiển mạng khi dùng. Đó là đặc tính của cách trang được xây dựng, không phải một lời hứa mà chúng tôi bắt bạn phải tin.

Lý do điều này quan trọng là tệp nằm cạnh CSR. Định nghĩa của chính CA/Browser Forum không khoan nhượng: "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 được máy chủ của người khác là đủ. Năm 2020, DigiCert phát hiện 337 khóa riêng mà khách hàng đã dán kèm với CSR của họ và thu hồi mọi chứng chỉ liên quan, ghi rằng "by sending the private key to DigiCert along with the CSR, the customer has compromised the private key". Nếu trang này từng đọc được một khóa riêng mà bạn dán vào, nó sẽ báo cho bạn, từ chối giải mã và không giữ lại gì.

Tệp thực sự đi đâuCA/Browser Forum TLS BR 2.3.1

Trang này

Trình duyệt của bạn
  1. Tệp được đọc
  2. Nó được tháo ra bằng mã đã đến cùng với trang
  3. Chữ ký được chính trình duyệt kiểm tra
  4. Kết quả được vẽ ra

Không yêu cầu nào rời đi mang theo dữ liệu của bạnMở bảng điều khiển mạng và quan sát khi bạn dùng

Một trang tải nó lên

Trình duyệt của bạn

Tệp được tải lên…cùng với bất cứ thứ gì được dán bên cạnh

Máy chủ của người khác

Khóa riêng đến đó đã bị lộ chỉ vì điều đó

“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.”

định nghĩa mà chính các tổ chức cấp chứng chỉ viết cho mình

Chuyện này đã xảy ra rồiNăm 2020, một tổ chức cấp chứng chỉ phát hiện 337 khóa riêng bị dán kèm bên cạnh một yêu cầuMọi chứng chỉ liên quan đều bị thu hồi

Không có gì trong một yêu cầu là bí mật, nên giải mã nó ở đâu cũng vô hại. Tệp mà người ta hay nhầm với nó thì khác, và thiệt hại không cần bị lạm dụng — chỉ cần bị nhìn thấy là đủ.

RSA hay ECDSA: CSR nên xin loại khóa nào?

Khóa ECDSA P-256 mạnh ngang khóa RSA 3072 bit mà nhỏ hơn nhiều, nên là lựa chọn mặc định tốt hơn. RSA 2048 vẫn được chấp nhận ở mọi nơi.

NIST xếp P-256 và RSA-3072 ở cùng mức an toàn 128 bit, và bảng của họ hoàn toàn không có dòng nào cho RSA-4096: dòng kế tiếp là RSA-7680, ở mức 192 bit, mức mà P-384 đạt được. Vì vậy khóa RSA 4096 bit 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 so với 3072. Baseline Requirements cũng cho phép P-521, nhưng Let's Encrypt từ chối nó, nên một yêu cầu P-521 có thể hoàn toàn hợp lệ mà vẫn thất bại ở CA bạn định dùng.

Ed25519 hiện không phải là lựa chọn cho chứng chỉ TLS công khai, dù thuật toán có tốt đến đâu: Baseline Requirements liệt kê RSA và ba đường cong NIST rồi thêm "no other algorithms or key sizes are permitted". Khóa hậu lượng tử cũng vậy — đề xuất bỏ phiếu có thể cho phép ML-DSA trong TLS công khai đã bị đóng mà không được hợp nhất vào tháng 10 năm 2026. Ed25519 và ML-DSA vẫn hữu ích cho SSH, cho việc ký và cho một CA riêng, và trang này đọc được các yêu cầu dùng chúng.

Cùng một mức an toàn, ở hai kích thước rất khác nhauNIST SP 800-57 Part 1 Rev 5, Table 2
Mức an toànKhóa RSAĐường cong
an toàn 112 bit2.048 bitCA công khai bất kỳKhông có đường cong nào mà tổ chức cấp chứng chỉ công khai cho phép ở mức an toàn này
an toàn 128 bit3.072 bitCA công khai bất kỳP-256CA công khai bất kỳ
4.096 bitCA công khai bất kỳ4.096 bit hoàn toàn không có trong bảng
an toàn 192 bit7.680 bitCA công khai bất kỳP-384CA công khai bất kỳ
an toàn 256 bit15.360 bitCA công khai bất kỳP-521CA công khai bất kỳ
  • Khóa RSA
  • Đường cong
  • Các bậc đi thẳng từ kích thước này sang kích thước kế tiếp và bỏ qua cái phổ biến ở giữa, nên công sức bắt tay thêm mà nó tốn của mỗi khách truy cập không mua được gì mà ai đó đã ghi lại
  • Được chấp nhận bởiLet's Encrypt

Một đường cong mang cùng mức an toàn trong một phần nhỏ số byte

Bảng so sánh đã công bố, cùng hai điều quyết định bạn có thực sự dùng được một khóa hay không: quy tắc cho phép gì, và tổ chức cấp chứng chỉ bạn định dùng cho phép gì.

Cách tạo CSR trên mọi nền tảng

Một lệnh OpenSSL phủ Linux, macOS và Windows đã cài OpenSSL. IIS có certreq, macOS có Keychain Access, và trang này có một công cụ tạo CSR không bao giờ gửi khóa của bạn đi đâu.

Với OpenSSL, openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" tạo khóa và yêu cầu trong một bước. (-nodes để khóa không mã hóa. OpenSSL 3 cũng viết là -noenc, nhưng LibreSSL tích hợp sẵn trong macOS chỉ biết -nodes.) Sau đó openssl req -in example.com.csr -text -verify -noout hiển thị và xác minh nó. Trên Windows, certreq -new request.inf request.req đọc một tệp .inf mà các tên thay thế nằm dưới OID 2.5.29.17 với các dòng _continue_ — không có khóa SAN=. Trang tham chiếu của chính Microsoft cảnh báo rằng ví dụ của họ dùng SHA-1, thứ mà CA giờ sẽ từ chối, nên hãy tự đặt hàm băm.

Trên máy Mac, Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority tạo một yêu cầu, với kích thước khóa nằm sau ô "Let me specify key pair information". Hoặc dùng công cụ tạo CSR của chúng tôi, tạo khóa bằng Web Crypto của trình duyệt và đưa cho bạn cả hai tệp mà không đi qua máy chủ nào. Không có tiêu chuẩn nào gán phần mở rộng tên tệp cho CSR: .csr, .pem, .req và .txt đều đang được dùng, và trang này đọc nội dung thay vì tin vào tên.

Bốn cách để tạo một CSROpenSSL · Microsoft Learn · Apple Support
  1. OpenSSLLinux, macOS, Windows

    Tạo khóa và yêu cầu chỉ trong một lệnhopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Rồi đọc lại và xác minh chữ ký của chính nóopenssl req -in example.com.csr -text -verify -noout
  2. certreqWindows Server và IIS

    Đọc một tệp văn bản thuần; các tên thay thế nằm trong một phần mở rộng, mỗi dòng một têncertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"Trang ví dụ của chính Microsoft vẫn được viết quanh một hàm băm mà tổ chức cấp chứng chỉ giờ từ chối, nên hãy tự đặt hàm băm
  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityMáy Mac của bạn đặt tên các menu này bằng ngôn ngữ của nóLoại và kích thước khóa nằm sau ô cho phép bạn chỉ định cặp khóaKhóa RSA từ 2048 đến 4096 bit; khóa nhỏ hơn không còn được cung cấp
  4. DNS RobotTrình duyệt bất kỳ

    Tạo khóa bằng mật mã của chính trình duyệt và đưa cho bạn cả hai tệp mà không tệp nào đi qua máy chủMở công cụ tạo CSR
Một lệnh OpenSSL chạy được trên Linux, macOS và Windows. Ba cách còn lại dành cho những máy không có sẵn lệnh đó.

Chứng chỉ sẽ có hiệu lực bao lâu?

Chứng chỉ TLS công khai cấp hôm nay không được vượt quá 200 ngày. Mức đó giảm xuống 100 ngày vào tháng 3 năm 2027 và 47 ngày vào tháng 3 năm 2029.

Lịch trình đến từ ballot SC-081v3 của CA/Browser Forum, được thông qua vào tháng 4 năm 2025, và CSR không thể tác động đến nó: thời hạn hiệu lực không bao giờ đến từ yêu cầu. Mỗi bước có hai con số, một mức SHOULD NOT thấp hơn mức MUST NOT một ngày — 199 và 200 hiện nay, 99 và 100 từ 15 tháng 3 năm 2027, 46 và 47 từ 15 tháng 3 năm 2029. Khi đếm, "a day is measured as 86,400 seconds", và một phần của ngày kế tiếp cũng được tính trọn một ngày.

Hệ quả thực tế là việc gia hạn phải tự động. Nếu bạn vẫn tạo CSR bằng tay mỗi năm, giờ là lúc chuyển sang ACME, nơi ứng dụng khách tạo yêu cầu thay bạn — và nhân tiện, ở đó PKCS#10 thật sự là bắt buộc, dù bản thân Baseline Requirements chỉ đòi "a certificate request in a form prescribed by the CA".

Chứng chỉ được phép có hiệu lực bao lâuCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. trước 15 tháng 3, 2026Hôm nay nằm ở đâu397 ngày398 ngày
  2. từ 15 tháng 3, 2026199 ngày200 ngày
  3. từ 15 tháng 3, 202799 ngày100 ngày
  4. từ 15 tháng 3, 202946 ngày47 ngày
  • Toàn bộ lịch trình đến từ một ballot, SC-081v3, được thông qua 11 tháng 4, 2025
  • Một ngày được tính chính xác là 86.400 giây và một phần của ngày kế tiếp cũng được tính trọn một ngày
  • Không có gì trong yêu cầu thay đổi được điều này
Bốn bước, mỗi bước có hai con số: một mức mà quy tắc không khuyến khích và một mức mà chúng cấm. Các ngày đã được cố định, và đó là điều khiến gia hạn tự động trở thành câu trả lời khả thi duy nhất.

ASN.1 thô cho bạn thấy gì

Bên dưới lớp base64, CSR là một cái cây mã hóa DER. Công cụ vẽ nó kèm vị trí byte và đặt tên cho mọi mã định danh đối tượng mà nó biết, đúng thứ mà openssl asn1parse in ra.

Đó là cách trung thực để hiển thị một trường mà không ai có tên thân thiện cho nó. Mở Cấu trúc thô trên bất kỳ mục nào đã giải mã và bạn sẽ thấy CertificationRequestInfo, từng relative distinguished name của chủ thể, SubjectPublicKeyInfo, tập attributes [0] và bên trong nó là thuộc tính extensionRequest — mã định danh đối tượng 1.2.840.113549.1.9.14, được định nghĩa không phải trong RFC 2986 mà trong RFC 2985 §5.4.2 — mang chính các phần mở rộng X.509 của RFC 5280.

Thuộc tính khác bạn có thể gặp ở đó là challengePassword (1.2.840.113549.1.9.7). Nó vốn là một bí mật chung để thu hồi chứng chỉ về sau, vẫn được SCEP dùng khi đăng ký, và không đóng vai trò gì trong việc đặt chứng chỉ web thông thường. Trang này hiển thị nó khi có, vì một trường bạn không nhìn thấy là một trường bạn không thể kiểm tra.

Cũng yêu cầu đó, dưới dạng byteRFC 2986 · RFC 2985 · RFC 5280
Tại byteCấu trúcKích thước
0SEQUENCE749 byte
4SEQUENCE469 byte
8INTEGER03 byte
11SEQUENCE108 byte
13SET13 byte
15SEQUENCE11 byte
17OBJECT IDENTIFIERC2.5.4.65 byte
22PrintableStringUS4 byte
26SET21 byte
28SEQUENCE19 byte
30OBJECT IDENTIFIERST2.5.4.85 byte
35UTF8StringCalifornia12 byte
47SET24 byte
49SEQUENCE22 byte
51OBJECT IDENTIFIERL2.5.4.75 byte
56UTF8StringSan Francisco15 byte
71SET22 byte
73SEQUENCE20 byte
75OBJECT IDENTIFIERO2.5.4.105 byte
80UTF8StringExample Inc13 byte
93SET26 byte
95SEQUENCE24 byte
97OBJECT IDENTIFIERCN2.5.4.35 byte
102UTF8Stringwww.example.com17 byte
119SEQUENCE294 byte
123SEQUENCE15 byte
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 byte
136NULL2 byte
138BIT STRING2.160 bit30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 byte
413[0]60 byte
415SEQUENCE58 byte
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 byte
428SET45 byte
430SEQUENCE43 byte
432SEQUENCE41 byte
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 byte
439OCTET STRING32 byte30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 byte
473SEQUENCE15 byte
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 byte
486NULL2 byte
488BIT STRING2.048 bit00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 byte
  • Chứa những thứ khác
  • Chứa một giá trị
  • Được đặt tên theo vị trí
  • Thuộc tính mang các phần mở rộng

    1.2.840.113549.1.9.14Nó được định nghĩa trong một tài liệu khác với tài liệu định nghĩa chính yêu cầu, đó là lý do các tên thay thế đi bên trong một thuộc tính thay vì nằm cạnh chủ thể
  • Thuộc tính khác bạn có thể gặpKhông có trong yêu cầu này

    1.2.840.113549.1.9.7Một bí mật chung, dùng để yêu cầu thu hồi chứng chỉ về sau, và vẫn được dùng khi một thiết bị tự đăng ký vào mạng
Từng byte của yêu cầu mẫu, với mỗi mã định danh đối tượng được đặt tên. Đây là thứ một công cụ giải mã dòng lệnh in ra, được vẽ thay vì in, để bạn thấy trường này kết thúc ở đâu và trường kế tiếp bắt đầu ở đâu.

Công cụ giải mã CSR: hỏi và đáp

Làm sao để giải mã một CSR?

Dán toàn bộ yêu cầu vào ô phía trên, gồm cả các dòng -----BEGIN CERTIFICATE REQUEST----- và -----END CERTIFICATE REQUEST-----, hoặc thả tệp lên trang. Nó được giải mã ngay khi bạn dán: chủ thể, khóa công khai, từng tên thay thế, từng phần mở rộng được yêu cầu và các dấu vân tay. Bạn cũng có thể dán riêng phần thân base64, một bản dump hex, hoặc tải lên tệp DER nhị phân.

Công cụ giải mã CSR này có an toàn không?

Có, và vì hai lý do. Yêu cầu ký chứng chỉ không chứa bí mật nào — nó vốn để gửi cho tổ chức cấp chứng chỉ — nên giải mã nó ở đâu cũng vô hại. Và trang này làm việc trong trình duyệt của bạn: yêu cầu được phân tích bằng mã tải về cùng với trang và không có gì được gửi đến máy chủ nào. Nếu bạn lỡ dán một khóa riêng, trang sẽ báo cho bạn, từ chối giải mã và không giữ lại gì.

Làm sao kiểm tra CSR của tôi có hợp lệ không?

Giải mã nó ở đây và đọc kết luận. Trang kiểm tra chữ ký của chính yêu cầu, thứ chứng minh người gửi giữ khóa riêng tương ứng, rồi áp dụng các quy tắc mà CA công khai áp dụng: các tên không được chứng nhận, wildcard quá rộng, địa chỉ IP dành riêng, khóa quá nhỏ hoặc phân tích được thừa số, trường chủ thể đã lỗi thời và hàm băm chữ ký cũ. Mỗi phát hiện cho biết CA sẽ từ chối, sẽ thay đổi hay chỉ ghi nhận.

Vì sao tổ chức cấp chứng chỉ từ chối CSR của tôi?

Các nguyên nhân thường gặp là một tên nội bộ như server.local hoặc tên máy chủ chỉ có một nhãn, dấu gạch dưới trong tên máy chủ, wildcard đặt trên một public suffix như *.co.uk, địa chỉ IP riêng tư trong các tên thay thế, khóa RSA dưới 2048 bit, hoặc yêu cầu vẫn ký bằng SHA-1. Hãy giải mã yêu cầu phía trên và từng điều đó đều được nêu rõ, kèm quy tắc mà nó vi phạm.

Làm sao biết khóa riêng của tôi khớp với CSR?

Dùng So khớp với một khóa hoặc chứng chỉ phía trên: thêm khóa bên cạnh yêu cầu và trang so sánh khóa công khai trong tệp khóa với khóa trong yêu cầu, ngay trong trình duyệt của bạn. Hoặc tự chạy — openssl req -in request.csr -pubkey -noout và openssl pkey -in private.key -pubout in ra cùng một khóa công khai khi chúng khớp nhau. Phép so sánh tương tự dùng được giữa một khóa và một chứng chỉ đã cấp.

Công cụ này giải mã được cả chứng chỉ SSL không?

Được. Dán một chứng chỉ và nó được giải mã như một chứng chỉ: đơn vị cấp và chủ thể, số sê-ri, ngày hiệu lực, từng tên thay thế, mục đích sử dụng khóa và mục đích sử dụng khóa mở rộng, các mã định danh khóa của đơn vị cấp và của chủ thể, URL OCSP và CA Issuers, chính sách chứng chỉ và mọi dấu thời gian certificate transparency được nhúng. Dán chứng chỉ cùng yêu cầu của nó và trang cũng cho bạn biết chúng có chung khóa không.

CA thực sự dùng những trường nào từ CSR của tôi?

Chắc chắn là một: khóa công khai. Tài liệu của chính DigiCert nói phần còn lại bị bỏ qua. Trên chứng chỉ OV hoặc EV, CA phải tự xác thực tổ chức và quốc gia trước khi đưa vào; ngày hiệu lực luôn lấy từ lịch trình của Baseline Requirements, không bao giờ từ yêu cầu. Hai trường không chỉ bị bỏ qua mà còn bị cấm trong chứng chỉ TLS công khai: OU và, trên chứng chỉ xác thực tên miền, emailAddress.

Tên chung còn quan trọng không?

Chỉ như một bản sao của thứ khác. Trình duyệt đã bỏ qua tên chung khi đối chiếu tên máy chủ từ năm 2017 và chỉ dùng các tên thay thế. Baseline Requirements ghi tên chung là NOT RECOMMENDED và yêu cầu rằng, nếu có, nó "MUST contain exactly one entry that is one of the values contained in the Certificate's subjectAltName extension". Một tên chung không nằm trong các tên thay thế của bạn là một lý do bị từ chối, và trang này đánh dấu nó.

Tôi có thể giải mã nhiều tệp cùng lúc không?

Được. Dán một yêu cầu, chứng chỉ của nó và các chứng chỉ trung gian cùng nhau, và mỗi khối được giải mã trên một thẻ riêng, theo thứ tự bạn dán. Một khối hỏng không làm dừng các khối khác. Nếu có khóa riêng ở đâu đó trong phần dán, nó được nêu tên và bỏ qua, không bao giờ được giải mã. Tối đa bốn mươi khối được giải mã và phần vượt quá được đếm và báo lại thay vì âm thầm bị bỏ.

Challenge password trong CSR là gì?

Một thuộc tính không bắt buộc từ RFC 2985, ban đầu là một bí mật chung bạn sẽ nêu ra khi yêu cầu thu hồi chứng chỉ. Nó vẫn có vai trò trong việc đăng ký SCEP, nơi một thiết bị chứng minh mình được phép xin. Nó không đóng vai trò gì trong việc đặt chứng chỉ web thông thường, và vì ít công cụ hiển thị trường này, trang này hiển thị nó mỗi khi một yêu cầu mang theo.

Tôi có thể dùng khóa Ed25519 cho chứng chỉ công khai không?

Hiện chưa. Baseline Requirements cho phép RSA và các đường cong P-256, P-384, P-521 rồi nêu rằng "no other algorithms or key sizes are permitted", nên không tổ chức cấp chứng chỉ công khai nào sẽ cấp cho một yêu cầu Ed25519. Đó là loại khóa tốt cho SSH, cho việc ký và cho một CA riêng, và công cụ giải mã này đọc các yêu cầu Ed25519 và Ed448, cùng khóa hậu lượng tử ML-DSA, mà không phàn nàn.

Hiện nay chứng chỉ có hiệu lực bao lâu?

Chứng chỉ TLS công khai cấp hôm nay không được vượt quá 200 ngày, giảm từ 398 trước ngày 15 tháng 3 năm 2026. Nó giảm xuống 100 ngày vào 15 tháng 3 năm 2027 và 47 ngày vào 15 tháng 3 năm 2029, theo ballot SC-081v3 của CA/Browser Forum. Không có gì trong CSR ảnh hưởng đến điều này; thời hạn do CA đặt. Với độ dài như vậy, việc gia hạn phải được tự động hóa, trên thực tế nghĩa là ACME.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới