в чем разница между .cer и pfx файлом [закрыто]

Раньше говорили -

cer - сертификат хранится в стандартном формате X.509. Этот сертификат содержит информацию о владельце сертификата ... вместе с открытым и закрытым ключами.

pfx - формат личного обмена. Он используется для обмена общедоступными и частными объектами в одном файле. Файл pfx можно создать из файла .cer. Также может использоваться для создания сертификата издателя программного обеспечения.

** получил реф по этой ссылке В чем разница между файлом cer, pvk и pfx? **

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

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

2 сценария, которые работают немного иначе:

СЦЕНАРИЙ 1:
Веб-браузер (клиент) обращается к веб-странице (серверу) через HTTPS с использованием SSL.

На сервере есть файл .PFX, содержащий оба ключа. Клиент подключается к веб-сайту на сервере, и сервер отправляет копию своего открытого ключа (файл .CER) Клиенту в рамках подтверждения SSL. Затем Клиент генерирует «SESSION-Key» и шифрует его, используя открытый ключ, полученный от сервера. Затем сеансовый ключ отправляется обратно на сервер и расшифровывается для подтверждения его подлинности. В случае успеха и клиент, и сервер теперь совместно используют «сеансовый ключ» для связи с использованием симметричного шифрования (то есть и клиент, и сервер, теперь оба шифруют И дешифруют все сообщения между собой, используя один и тот же сеансовый ключ. Все это выполняется за кулисами в фоновом режиме веб-браузера, между моментом ввода URL-адреса в адресной строке и появлением веб-страницы.

СЦЕНАРИЙ 2:
Приложение (клиент) подключается к FTP-сайту (серверу)
или
удаленному рабочему столу (клиент-сервер) с помощью SSH
(применимы оба примера)

В этом случае, как клиент и сервер будут иметь свои собственные частные и государственные пары ключей
(в отличии от других примеров , приведенных в этой теме, что только объяснить , когда сервер имеет оба ключа, и клиент имеет только открытый ключ)

Теперь в целях объяснения - давайте обозначим пары ключей примерно так:
A1 и A2 = как закрытый и открытый ключи серверов соответственно
B1 и B2 = как закрытый и открытый ключи клиента соответственно.

Используя эту модель, в предыдущих сообщениях в этой ветке говорилось о том, что Сервер имеет A1 и A2 ( файл .PFX ) и предоставляет клиентам только копию A2 ( .CER ).

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

Теперь у сервера есть A1 ( собственный частный ), A2 ( собственный публичный ) и копия B2 ( общедоступный
клиент ). У клиента теперь есть B1 ( собственный частный ), B2 ( собственный публичный ) и копия A1 ( общедоступный сервер). Общедоступный )

Связь между
клиентом и сервером: клиент использует 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).