у чому різниця між файлом .cer та pfx [закрито]

Люди говорили -

cer - сертифікат, що зберігається у стандартному форматі X.509. Цей сертифікат містить інформацію про власника сертифіката ... разом із відкритими та приватними ключами.

pfx - означає персональний формат обміну. Він використовується для обміну загальнодоступними та приватними об’єктами в одному файлі. Файл pfx можна створити з файлу .cer. Також може використовуватися для створення сертифіката видавця програмного забезпечення.

** отримав посилання за цим посиланням Яка різниця між файлами cer, pvk та pfx? **

але ніхто не каже, коли нам слід використовувати файл CERT, а коли - файл PFX. Будь ласка, обговоріть ситуацію, коли нам слід вибрати файл CERT, а коли файл PFX. Дякую.

.Pfx включає як відкритий, так і приватний ключ відповідного сертифіката (НІКОЛИ не діліться цим за межами вашої організації); його можна використовувати для TLS / SSL на веб-сайті, для цифрового підписання повідомлень або маркерів авторизації або для аутентифікації в партнерській системі. Файл .cer має лише відкритий ключ (саме цим ви зазвичай обмінюєтесь з партнерами по інтеграції); його можна використовувати для перевірки токенів або запитів автентифікації клієнта, і це те, що отримує клієнт HTTP від ​​сервера в рукостисканні SSL.

2 x сценарії, які працюють дещо інакше:

СЦЕНАРІЙ 1:
Веб-браузер (клієнт), який отримує доступ до веб-сторінки (сервера) через HTTPS за допомогою SSL.

Сервер має файл .PFX, що містить обидва ключі. Клієнт підключається до веб-сайту на сервері, а сервер надсилає копію свого відкритого ключа (файл .CER) клієнту як частину рукостискання SSL. Потім Клієнт генерує "SESSION-ключ" і шифрує його за допомогою відкритого ключа, отриманого від сервера. Потім ключ сеансу відправляється назад на сервер і розшифровується для підтвердження його справжності. У разі успіху і клієнт, і сервер тепер мають спільний «ключ сеансу» для спілкування за допомогою симетричного шифрування (тобто і клієнт, і сервер, тепер обидва шифрують І дешифрують всі повідомлення між собою за допомогою одного і того ж ключа сеансу. Все це відбувається робиться за кулісами у фоновому режимі веб-браузера, між тим, як ви вводите URL-адресу в адресний рядок, і коли з’являється веб-сторінка.

СЦЕНАРІЙ 2:
Додаток (клієнт) підключається до FTP-сайту (сервера)
або
віддаленого робочого столу (клієнта до сервера) за допомогою SSH
(застосовуються обидва приклади)

У цьому випадку, як клієнт і сервер будуть мати свої власні приватні і державні пари ключів
(на відміну від інших прикладів , наведених в цій темі, що тільки пояснити , коли сервер має обидва ключа, і клієнт має тільки відкритий ключ)

Тепер для пояснення - Давайте
позначимо пари ключів приблизно так: A1 і A2 = як приватні та відкриті ключі серверів відповідно
B1 та B2 = як приватні та відкриті ключі клієнтів відповідно

Використовуючи цю модель, у попередніх повідомленнях у цій темі говорилося про те, коли на сервері є А1 і А2 ( файл .PFX ), і надає клієнтам лише копію А2 ( .CER )

Тоді як з'єднання FTP або SSH (є й інші приклади) складаються з ключів A1 , A2 , B1 і B2 у всьому зв'язку клієнт-сервер. Наприклад,
- Клієнт підключається до FTP-сервера.
- Сервер надсилає Клієнту копію свого відкритого ключа (A2).
- Клієнт надсилає власний відкритий ключ (B2) назад на Сервер, завершуючи рукостискання.
- Зараз буде використовуватися асиметричне шифрування

Сервер тепер має A1 , ( власний приватний ), A2 ( власний загальнодоступний ) та копію B2 ( Public of Client ).
Клієнт тепер має B1 , ( власний Private ), B2 ( власний загальнодоступний ) та копію A1 ( Server Публічний )

Клієнт-серверні повідомлення:
Клієнт використовує A2 (відкритий ключ сервера) для шифрування повідомлень, призначених для Сервера, Сервер розшифровує їх за допомогою A1 (Серверний приватний ключ)

Комунікації між сервером і клієнтом:
сервер використовує B2 (відкритий ключ клієнта) для шифрування повідомлень, пов’язаних з клієнтом, клієнт розшифровує їх за допомогою B1 (приватний ключ клієнта)

Що стосується типів файлів .CER та .PFX, Сервер має власний файл .PFX, який не повинен розповсюджуватися за межами вашої організації, натомість вам слід розповсюджувати файл .CER серед клієнтів.

більше інформації можна знайти тут:
https://www.digicert.com/ssl-cryptography.htm

і тут:
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client

З мого досвіду (він не такий обширний, як я хочу), я використовую файл pfx під час налаштування прив'язки https на сервері IIS (оскільки він містить як відкритий, так і приватний ключ, з цим файлом у вас все гаразд), файл cer - це лише загальнодоступна частина пари ключів (більшість випадків), і вам потрібно використовувати його разом із файлом .key під час налаштування ssl-трафіку на сервері nginx або apache,

Наскільки я розумію, немає більше важких причин використовувати ту чи іншу,

Як вже зазначалося, питання полягає в трохи яблук та апельсинів, оскільки файл cer - це лише відкритий ключ, але файл pfx містить як відкритий, так і приватний ключі.

Тож більш справедливим буде питання, коли ви хочете використовувати файл pfx на відміну від файлу pem. Враховуючи те, що файли pfx критикували за надмірну складність, справедливою відповіддю на ваше друге запитання може бути така: ви коли-небудь захочете використовувати файл pfx лише в тому випадку, якщо у вас запущений IIS, і його конфігурація абсолютно не дозволяє вам використовувати щось інше .

Джерело: https://en.wikipedia.org/wiki/PKCS_12 (Примітка, на яку посилається стаття Пітера Гутмана.)

SSL використовує асинхронне шифрування, що означає, що один ключ (приватний ключ) передається серверу, який «володіє» парою ключів, тоді як інший ключ (відкритий ключ) розповсюджується вільно. Оскільки власник хоче залишити цей приватний ключ приватним, він буде захищений паролем і переданий ТІЛЬКИ серверу-власнику (часто у файлі PFX або P12). Але відкритий ключ буде розповсюджуватися вільно (часто у файлі CER).
Він називається асинхронним, оскільки дані, зашифровані за допомогою приватного ключа, можуть бути розшифровані лише за допомогою відкритого ключа, тоді як дані, зашифровані за допомогою відкритого ключа, можуть бути розшифровані лише за допомогою закритого ключа. Отже, якщо ви хочете надіслати щось надійно власнику, ви зашифруєте це за допомогою його приватного ключа, і він буде єдиним, хто зможе це розшифрувати. Якщо власник хоче довести, що він щось надіслав, він зашифровує це за допомогою приватного ключа, і кожен, хто має відкритий ключ, може його розшифрувати. (Після встановлення сертифікатів це зазвичай робиться за кулісами браузером або інструментом електронної пошти.)