sự khác biệt giữa tệp .cer & pfx [đã đóng]


82

Người ta thường nói -

cer - chứng chỉ được lưu trữ ở định dạng tiêu chuẩn X.509. Chứng chỉ này chứa thông tin về chủ sở hữu chứng chỉ ... cùng với các khóa công khai và riêng tư.

pfx - là viết tắt của định dạng trao đổi cá nhân. Nó được sử dụng để trao đổi các đối tượng công cộng và riêng tư trong một tệp duy nhất. Tệp pfx có thể được tạo từ tệp .cer. Cũng có thể được sử dụng để tạo Chứng chỉ nhà xuất bản phần mềm.

** lấy tham chiếu từ liên kết này Sự khác biệt giữa tệp cer, pvk và pfx là gì? **

nhưng không ai nói khi nào chúng ta nên sử dụng tệp CERT và khi nào chúng ta nên sử dụng tệp PFX. Nếu có thể, vui lòng thảo luận về tình huống khi nào chúng ta nên sử dụng tệp CERT và khi nào chúng ta nên sử dụng tệp PFX. Cảm ơn.


Ngoài ra [1] , [2] , [3]
Pacerier

Câu trả lời:


98

A .pfx bao gồm cả khóa công khai và khóa riêng tư cho chứng chỉ được liên kết (KHÔNG BAO GIỜ chia sẻ điều này ra bên ngoài tổ chức của bạn); nó có thể được sử dụng cho TLS / SSL trên trang web, để ký kỹ thuật số thông báo hoặc mã thông báo ủy quyền hoặc để xác thực với hệ thống đối tác. Tệp .cer chỉ có khóa công khai (đây là những gì bạn thường trao đổi với các đối tác tích hợp); nó có thể được sử dụng để xác minh mã thông báo hoặc yêu cầu xác thực máy khách và nó là thứ được máy khách HTTP nhận từ máy chủ trong quá trình bắt tay SSL.


trong trường hợp tệp cert nơi lưu trữ khóa cá nhân? tôi thấy hầu hết mọi người sử dụng tệp cert với wcf ... tại sao? tại sao họ không chọn tệp pfx? cái nào an toàn nhất?
Thomas

u đã bỏ lỡ một điểm quan trọng mà khi mọi người sử dụng tệp cert và khi tệp pfx ... nó là quan trọng nhất. cảm ơn về câu trả lời.
Thomas

Tệp cert là một thuật ngữ chung cho Chứng chỉ X.509. Trong thế giới Windows, pfx được bảo vệ bằng mật khẩu và không bao giờ được rời khỏi tổ chức. Tệp chứng nhận có thể được xuất từ ​​chứng chỉ X.509 dưới dạng khóa công khai. Nếu bạn đang sử dụng chứng chỉ X.509 từ máy khách WCF để ký hoặc xác thực thư, bạn sẽ cần cài đặt (hoặc có sẵn trong một thư mục) tệp pfx. Tôi đã bỏ lỡ điều gì @Thomas?
PeterB

1
làm ơn trả lời câu hỏi thứ hai của tôi.
Thomas

3
@Thomas Bạn có thể lặp lại không? Bài đăng của bạn không có dấu chấm hỏi, vì vậy rất khó để biết những gì chưa được trả lời. BTW, một tệp chứng nhận KHÔNG bao gồm khóa riêng. ;)
PeterB

9

2 x kịch bản hoạt động hơi khác một chút:

KỊCH BẢN 1:
Trình duyệt Web (Máy khách) truy cập Trang Web (Máy chủ) qua HTTPS bằng SSL.

Máy chủ có Tệp .PFX chứa cả hai khóa. Máy khách kết nối với Trang web trên Máy chủ và Máy chủ gửi bản sao Khóa công khai (tệp .CER) của nó cho Máy khách như một phần của quá trình bắt tay SSL. Sau đó, Máy khách tạo một "SESSION-Key" và mã hóa nó bằng cách sử dụng khóa công khai nhận được từ máy chủ. Khóa phiên sau đó được gửi trở lại máy chủ và được giải mã để xác nhận tính xác thực của nó. Nếu thành công, cả Máy khách và Máy chủ hiện chia sẻ "Khóa phiên" để giao tiếp bằng cách sử dụng mã hóa đối xứng (tức là cả máy khách và máy chủ, giờ đây cả hai đều mã hóa VÀ giải mã tất cả các thông báo giữa nhau bằng cùng một khóa phiên. Tất cả điều này đang được được thực hiện ở hậu trường trong nền của trình duyệt web, giữa thời điểm bạn nhập URL vào thanh địa chỉ và nhìn thấy trang web xuất hiện.

SCENARIO 2:
Ứng dụng (Máy khách) kết nối với Trang web FTP (Máy chủ)
hoặc
Máy tính từ xa (Máy khách đến Máy chủ) bằng SSH
(cả hai ví dụ sẽ áp dụng)

Trong tình huống này, cả các Client và Server sẽ có tư nhân và công cộng của cặp khóa của họ
(trái ngược với các ví dụ khác được đề cập trong chủ đề này, mà chỉ giải thích khi một máy chủ có cả các phím, và khách hàng có khóa công khai chỉ)

Bây giờ, với mục đích giải thích - Hãy gắn nhãn các cặp Khóa giống như:
A1A2 = làm Khóa Riêng tư và Khóa Công khai của Máy chủ Tương ứng
B1B2 = là Khóa Riêng tư và Khóa Công khai của Khách hàng

Sử dụng mô hình này, các bài viết trước trong chủ đề này đã nói về thời điểm Máy chủ có A1A2 ( tệp .PFX ) và chỉ chia sẻ bản sao của A2 ( .CER ) với máy khách

Trong khi các kết nối FTP hoặc SSH (có các ví dụ khác ở đó) bao gồm các Khóa A1 , A2 , B1B2 trong toàn bộ Giao tiếp Máy khách-Máy chủ. Ví dụ,
- Máy khách kết nối với Máy chủ FTP.
- Máy chủ Gửi bản sao của Khóa công khai (A2) cho Máy khách.
- Máy khách gửi khóa công khai của chính mình (B2) trở lại Máy chủ, hoàn tất quá trình bắt tay.
- Điều này bây giờ sẽ được sử dụng Mã hóa không đối xứng

Máy chủ hiện có A1 , ( Riêng tư của chính nó ), A2 ( công khai của riêng nó ) và bản sao của B2 ( Công khai của
Máy khách ) Máy khách hiện có B1 , ( Riêng tư của chính nó ), B2 ( công khai của riêng nó ) và Bản sao của A1 ( của Máy chủ Công khai )

Giao tiếp giữa máy khách với máy chủ:
Máy khách sử dụng A2 (khóa công khai của máy chủ) để mã hóa các thông báo liên kết với Máy chủ, Máy chủ giải mã chúng bằng A1 (Khóa riêng của máy chủ)

Server-To-client Comms:
Server sử dụng B2 (khóa công khai của máy khách) để mã hóa thông báo liên kết với Máy khách, Máy khách giải mã chúng bằng B1 (Khóa riêng của máy khách)

Về Loại tệp .CER và .PFX, Máy chủ không có .PFX của riêng nó không nên được phân phối ra bên ngoài tổ chức của bạn, thay vào đó, bạn nên phân phối tệp .CER ra cho Khách hàng.

có thể tìm thấy thêm thông tin tại đây:
https://www.digicert.com/ssl-cryptography.htm

và tại đây:
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client


0

Theo kinh nghiệm của tôi (nó không rộng như tôi muốn) tôi sử dụng tệp pfx khi định cấu hình liên kết https trên máy chủ IIS (vì tệp này chứa cả khóa công khai và khóa riêng tư, bạn chỉ cần tệp đó là ổn), tệp cer chỉ là phần công khai của cặp khóa (hầu hết các trường hợp) và bạn cần sử dụng nó cùng với tệp .key khi định cấu hình lưu lượng ssl trên máy chủ nginx hoặc apache,

Theo như tôi hiểu thì không có lý do khó khăn nào hơn để sử dụng cái này hay cái kia,


0

Như đã được đề cập, câu hỏi hơi táo và cam, vì tệp cer chỉ là khóa công khai nhưng tệp pfx chứa cả khóa công khai và riêng tư.

Vì vậy, một câu hỏi công bằng hơn sẽ là khi nào bạn muốn sử dụng tệp pfx thay vì tệp pem. Cho rằng các tệp pfx đã bị chỉ trích là quá phức tạp, câu trả lời hợp lý cho câu hỏi thứ hai của bạn có thể là: bạn chỉ muốn sử dụng tệp pfx nếu bạn đang chạy IIS và cấu hình của nó hoàn toàn không cho phép bạn sử dụng bất kỳ thứ gì khác .

Nguồn: https://en.wikipedia.org/wiki/PKCS_12 (Chú thích được tham chiếu là một bài báo của Peter Gutmann.)


-2

SSL sử dụng mã hóa không đồng bộ, có nghĩa là một khóa (khóa riêng) được trao cho máy chủ "sở hữu" cặp khóa, trong khi khóa khác (khóa công khai) được phân phối tự do.
Nó được gọi là không đồng bộ vì dữ liệu được mã hóa bằng khóa riêng chỉ có thể được giải mã bằng khóa công khai, trong khi dữ liệu được mã hóa bằng khóa công khai chỉ có thể được giải mã bằng khóa riêng. Vì vậy, nếu bạn muốn gửi một thứ gì đó một cách an toàn cho chủ sở hữu, bạn mã hóa nó bằng khóa riêng của họ và anh ta sẽ là người duy nhất có thể giải mã nó. Nếu chủ sở hữu muốn chứng minh rằng anh ta đã gửi thứ gì đó, anh ta sẽ mã hóa nó bằng khóa cá nhân và bất kỳ ai có khóa công khai đều có thể giải mã nó. (Sau khi các chứng chỉ được cài đặt, điều này thường được thực hiện đằng sau bởi trình duyệt hoặc công cụ email.)
Vì chủ sở hữu muốn giữ khóa riêng tư đó ở chế độ riêng tư, nó sẽ được bảo vệ bằng mật khẩu và CHỈ được cấp cho máy chủ sở hữu (thường trong tệp PFX hoặc P12). Nhưng khóa công khai sẽ được phân phối tự do (thường trong tệp CER).


"bạn mã hóa nó bằng khóa riêng của anh ấy và anh ấy sẽ là người duy nhất có thể giải mã nó." Tôi nghĩ ý bạn là bạn mã hóa nó bằng khóa công khai của anh ấy.
Dave Goldsmith

1
Tôi nghĩ ý bạn là "không đối xứng", không phải "không đồng bộ".
Nate Barbettini,

Bạn đúng một phần - nó sử dụng cả mã hóa không đối xứng và đối xứng. SSL sử dụng mã hóa không đối xứng ban đầu giữa máy khách và máy chủ - nhưng chỉ đến thời điểm mà máy khách có thể xác minh độ tin cậy và tạo khóa đối xứng, gửi lại khóa đó đến máy chủ (sử dụng mã hóa không đối xứng) và sau đó tất cả giao tiếp dữ liệu thực sẽ xảy ra sử dụng mã hóa đối xứng.
Aaron Krauss
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.