сертификат pfx для чего
в чем разница между.файл cer & pfx
* * получил ref из этой ссылки что является ли разница между файлом cer, pvk и pfx?**
но никто не говорит, Когда мы должны использовать файл сертификата и когда мы должны использовать файл PFX. Если возможно, пожалуйста, обсудите ситуацию, когда мы должны пойти на файл сертификата & когда мы должны пойти на файл PFX. Спасибо.
4 ответов
насколько я понимаю, нет более сложных причин для использования тот или другой,
Как уже упоминалось, вопрос немного яблок и апельсинов, так как файл cer является только открытым ключом, но файл pfx содержит как открытые, так и закрытые ключи.
таким образом, более справедливым вопросом было бы, когда вы хотите использовать файл pfx, а не файл pem. Учитывая, что pfx-файлы были подвергнуты критике за чрезмерную сложность, справедливым ответом на ваш второй вопрос может быть: вы только когда-либо захотите использовать файл pfx, если вы используете IIS и его конфигурацию абсолютно не позволит вам использовать что-либо еще.
источник:https://en.wikipedia.org/wiki/PKCS_12 (Ссылка на сноску-это статья Питера Гутмана.)
SSL использует асинхронное шифрование, что означает, что один ключ (закрытый ключ) предоставляется серверу, который «владеет» парой ключей, в то время как другой ключ (открытый ключ) распространяется свободно.
Он называется асинхронным, поскольку данные, зашифрованные с помощью закрытого ключа, могут быть расшифрованы только с помощью открытого ключа, а данные, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с помощью закрытого ключа. Поэтому, если вы хотите отправить что-то владельцу, вы зашифруете его с помощью его закрытого ключа и он будет единственным, кто сможет расшифровать его. Если владелец хочет доказать, что он что-то послал, он шифрует это закрытым ключом, и любой, у кого есть открытый ключ, может расшифровать его. (После установки сертификатов это обычно делается за кулисами браузером или инструментом электронной почты.)
Поскольку владелец хочет сохранить этот закрытый ключ закрытым, он будет защищен паролем и предоставлен только серверу-владельцу (часто в файле PFX или P12). Но открытый ключ будет распространяться свободно (часто в файле CER).
Сертификат pfx для чего
Добрый день уважаемые читатели, в прошлый раз я вам рассказывал, о том, что такое csr запрос и мы его генерировали на IIS сервере, далее нам его нужно было передать в удостоверяющий центр для выпуска основного сертификата сервера, мы выбрали для этих целей сертификат comodo на 3 года от компании Emaro. Все замечательно, сертификат прислали, но есть одно но, когда вы попытаетесь импортировать сертификат в формате crt в IIS сервере, то получите предложение, только на импорт pfx формата, и если его не, то ошибку, что сертификат не содержит закрытого ключа. Давайте смотреть как это решить.
Для чего нужно преобразование сертификатов
Тут ответ, очень простой, все дело в формате работы с ними у каждой программы, будь то IIS или же Apache сервер. Более подробно про виды сертификатов и их назначение, я вам посоветую прочитать вот эту статью.
Давайте я подробнее покажу как выглядит ошибка импортирования сертификата. Во первых когда вы получаете от comodo ваш архив с сертификатами, то там будет два файла:
Попытавшись на сервере IIS произвести их импорт вы увидите вот такую картинку.
И тут нет ничего удивительного, так как это не pfx архив, то в нем нет нужного приватного ключа. Для его получения придется слегка постараться.
Как получить PFX ключ на IIS
нажимаем сочетание клавиш WIN+R и вводим mmc, для вызова оснастки. Я вам уже рассказывал о ее применении и удобстве для системного администратора.
Далее вам необходимо через меню «Файл» добавить новую оснастку.
Находим сертификаты и нажимаем кнопку «Добавить»
В следующем окне выбираем «для учетной записи компьютера»
подтверждаем, что нас интересует локальный компьютер.
Далее находим пункт «Запросы заявок на сертификат», тут вы обнаружите ваш запрос, находите его и через правый клик экспортируете его.
У вас откроется мастер экспорта сертификатов
Далее вы выбираете «Да, экспортировать закрытый ключ»
Ставим галку «Включить по возможности все сертификаты в путь сертификации» и начинаем наш экспорт PFX архива.
Теперь мастер экспорта, просит вас указать два раза нужный вам пароль, для защиты pfx архива.
Через кнопку обзор, указываем место сохранения вашего файла.
Как видим, все успешно выгружено.
Установка OpenSSL для Windows
Теперь нам необходимо наш файл pfx переделать в pem, Pem преобразовать в key:
Вы получите из этих трех файлов, нужный для импорта pfx архив. Во всем этом нам поможет утилита OpenSSL для Windows.
В итоге у вас будет архив, распакуйте его куда вам будет угодно. Далее выберите вашу папку, зажмите SHIFT и щелкните по ней правым кликом, в открывшемся контекстном меню, выберите пункт «Открыть окно команд».
В результате чего у вас откроется командная строка Windows, но уже в нужной папке содержащей утилиту openssl.exe, она нам и поможет все сделать красиво.
Преобразование PFX в PEM
Теперь приступаем к получению фала в формате Pem. Положите в папку с дистрибутивом файл в формате pfx.
Вас попросят указать пароль от Pfx архива, вы его задавали при экспорте, после чего нужно придумать пароль на pem файл.
В папке с дистрибутивом OpenSSL вы обнаружите файл key.pem, он нам нужен будет для следующего этапа.
Преобразование PEM в KEY
Теперь получим файл с расширением key, для этого есть вот такая команда:
Вас попросят указать пароль от pem ключа.
В итоге я получил закрытый ключ в формате key.
Осталась финишная прямая.
Получаем PFX ключ для импорта в IIS
Теперь когда у вас есть все составляющие, вы можете выполнить последнюю команду для создания PFX файла для IIS сервера.
Задаем пароль для pfx файла, потребуется при импортировании.
В итоге вы получаете нужный вам файл, который можно загружать на ваш почтовый сервер.
Что делать если нет сертификата в запросах заявок на сертификат
Бывают ситуации, что на вашем сервере по каким-то причинам, в папке запросы на сертификат, может не оказаться вашего, в этом случае вам необходимо будет перейти в этой же mmc в раздел «Личное-Сертификаты». Выбираем нужный и делаем экспорт.
Появится мастер экспорта сертификатов.
Обратите внимание, что в pfx выгрузить не получится, но это не страшно, нам подойдет и p7b, но с включенной галкой «Включить по возможности все сертификаты в путь сертификации»
Указываем путь сохраняемого файла.
Видим, что все успешно выполнено.
Преобразование p7b в pem
Попробует такое преобразование.
В итоге я получил файл new.pyatilistnik.ru.pem
Ну, а дальше уже по инструкции сверху. Если у вас выскочит ошибка, по типу
Преобразование CRT в PEM
Кладем так же все в одну папку, файл crt вам должны были прислать вместе с ca-bundle.
Варианты хранения криптографических ключей
Продолжает расти популярность решений на основе PKI — всё больше сайтов переходят на HTTPS, предприятия внедряют цифровые сертификаты для аутентификации пользователей и компьютеров, S/MIME доказывает свою состоятельность и для шифрования электронной почты, и как способ проверки источника сообщений для противодействия фишингу. Но шифрование и аутентификация в этих приложениях практически бессмысленны без правильного управления ключами.
Каждый раз при выдаче цифрового сертификата от центра сертификации (ЦС) или самоподписанного сертификата нужно сгенерировать пару из закрытого и открытого ключей. Согласно лучшим практикам, ваши секретные ключи должны быть защищены и быть, ну… секретными! Если кто-то их получит, то сможет, в зависимости от типа сертификата, создавать фишинговые сайты с сертификатом вашей организации в адресной строке, аутентифицироваться в корпоративных сетях, выдавая себя за вас, подписывать приложения или документы от вашего лица или читать ваши зашифрованные электронные письма.
Во многих случаях секретные ключи — личные удостоверения ваших сотрудников (и, следовательно, часть персональных данных организации), так что их защита приравнивается к защите отпечатков пальцев при использовании биометрических учётных данных. Вы же не позволите хакеру добыть отпечаток своего пальца? То же самое и с секретными ключами.
В этой статье мы обсудим варианты защиты и хранения закрытых ключей. Как вы увидите, эти варианты могут незначительно отличаться в зависимости от типа сертификата(ов) и от того, как вы его используете (например, рекомендации для сертификатов SSL/TLS отличаются от рекомендаций для сертификатов конечных пользователей).
Хранилища сертификатов/ключей в ОС и браузерах
Примеры: хранилище сертификатов Windows, связка ключей Mac OS
В некоторых операционных системах и браузерах есть хранилища сертификатов или ключей. Это программные базы данных, которые локально на вашем компьютере хранят пару из закрытого и открытого ключей как часть сертификата. Такое хранение ключей довольно популярно: многие приложения автоматически сразу ищут ключи здесь, и не нужно вручную каждый раз указывать файл сертификата, так что это довольно удобный вариант.
Ещё один плюс такого варианта — его довольно легко настраивать. Вы можете включить/отключить экспорт закрытого ключа, включить для него надёжную защиту (ввод пароля при каждом использовании сертификата), и можно создать резервные копии, если закрытый ключ экспортируется. Кроме того, при включении роуминга профилей в Windows сертификат привязывается к профилю и становится доступным при входе на другой компьютер с этим профилем.
Если решите выбрать такой вариант, то следует учесть несколько аспектов. Во-первых, даже если пометить закрытый ключ как неэкспортируемый, некоторые утилиты могут обойти эту защиту (то есть невозможность экспорта не гарантирована). Кроме того, если кто-то работал под вашей учётной записью, а вы не включили сильную защиту закрытого ключа (пароль при использовании сертификата), то они могут использовать ваш сертификат. Наконец, если ваш закрытый ключ помечен как экспортируемый, то кто-нибудь за вашим компьютером сможет экспортировать его. Даже если у вас включена защита секретного ключа, при экспорте пароль не спрашивается.
И последнее: Chrome и IE используют хранилище сертификатов Windows, в то время как у Firefox собственное хранилище сертификатов (от Mozilla). Это значит, что если вы импортируете сертификат в хранилище Windows, то Chrome и IE автоматически найдут его, а Firefox нет.
Типичные приложения:
Если решите сохранить файл на удалённом сервере, то следует особенно позаботиться об ограничении доступа к нему. Если кто-то получит доступ, то сможет использовать ваш сертификат. Аналогично, следует быть особенно осторожным с лёгким копированием и распространением этих файлов. Хотя это и большое удобство для вас, но одновременно и злоумышленнику будет просто сделать копию, если он получит доступ к вашему хранилищу ключей. Пароль закрытого ключа по-прежнему необходим для эффективного использования скопированного файла. Это еще одна причина, чтобы использовать надёжные пароли из 15-ти и больше символов, содержащие заглавные буквы, цифры и специальные символы. С этим вариантом хранения нужно учитывать ещё одну вещь: на конечного пользователя накладывается больше ответственности с точки зрения того, где находится файл и правильно ли он хранится.
Если вы не можете использовать криптографическое оборудование или хранилище ключей Windows (описано выше), но всё же хотите повысить безопасность (вместо того, чтобы просто разместить файл хранилища ключей на компьютере), то можно записать этот файл на флэшку, которая будет лежать в безопасном месте. Конечно, здесь теряется некоторое удобство, так что если нужно часто использовать подпись, то вы скорее захотите хранить файл локально для облегчения доступа.
Типичные приложения:
Криптографические токены и смарт-карты
Как вскользь упомянуто выше, можно повысить безопасность, если хранить секретный ключ на отдельном оборудовании. Но есть большая разница между использованием криптографических токенов или смарт-карт и стандартных флэш-накопителей. С криптографическим оборудованием ключ генерируется на самом оборудовании и не экспортируется. Закрытый ключ никогда не покидает устройство, что сильно затрудняет постороннему получение доступа и компрометацию.
С токеном каждый раз при использовании сертификата нужно вводить пароль. Это значит, что даже если кто-то получит ваш токен, ему всё равно понадобится пароль. Хранение ключа в токене означает, что вы можете безопасно использовать один и тот же сертификат на нескольких компьютерах без необходимости создания нескольких копий и прохождения процесса экспорта/импорта. Криптографическое оборудование соответствует FIPS, что требуется для некоторых отраслевых и государственных регламентов.
Конечно, есть некоторые другие соображения, которые следует иметь в виду, если вы решите выбрать такой вариант. Кроме дополнительных сложностей управления токенами, такой вариант может не работать с автоматическими сборками из-за требования ввести пароль при каждом использовании сертификата. Также нет никакого способа создать резервную копию сертификата, поскольку закрытый ключ не экспортируется (недостаток дополнительной безопасности). Наконец, в некоторых сценариях такой вариант хранения просто невозможен. Например, если специализированные устройства не поддерживают токены или смарт-карты. Или в ситуациях, когда сотрудники не имеют физического доступа к компьютеру, а работают с удалённых терминалов.
Типичные приложения:
Как правило, все варианты использования, перечисленные для хранилищ в ОС/браузере (подпись документов и кода, аутентификация клиента, Windows IIS), поддерживают крипто-токены или смарт-карты — если есть соответствующие драйверы. Однако это не всегда практично (например, в веб-серверах или автоматизированных системах сборки для подписи кода, которые будут требовать ввод пароля каждый раз при применении подписи).
Соответствие нормативным требованиям — одна из основных причин использования криптографических токенов.
Аппаратные криптографические модули (HSM)
HSM — ещё одно аппаратное решение для хранения ключей, особенно если вы не хотите полагаться на отдельные токены либо это кажется слишком обременительным. В то время как токены больше ориентированы на ручной ввод или отдельные приложения (например, подписание небольшого количества документов или кода, аутентификация в VPN или других сетях), то HSM предоставляют API, поддерживают автоматизированные рабочие процессы и автоматизированную сборку. Они также соответствуют требованиям FIPS и обычно обеспечивают более высокий рейтинг, чем токены.
Традиционно HSM — это локальные физические устройства, требующие квалифицированных ресурсов для управления и обеспечения базовых требований и SLA. Обслуживание HSM может оказаться дорогим и ресурсоёмким процессом, что в прошлом препятствовало распространению этой технологии. К счастью, в последние годы появились облачные модули HSM, которые предоставляют многие из преимуществ локальных HSM, не нуждаясь в локальном обслуживании.
Примером может служить знакомый многим сервис Key Vault в облаке Microsoft Azure, которое хранит криптографические ключи в облачном HSM от Microsoft. Если у вас небольшая организация, которая не позволит себе покупку и управление собственным HSM, то это отличное решение, которое интегрируется с публичными центрами сертификации, включая GlobalSign.
Если вы рассматриваете вариант с подписью документов, то недавно мы запустили новую службу Digital Signing Service, где тоже используется облачное хранилище HSM для закрытых ключей. Стоит отметить, что новая служба поддерживает индивидуальные подписи всех сотрудников. В прошлом в большинстве HSM-решений для подписи поддерживались только идентификаторы на уровне отделов или организаций (например, бухгалтерия, маркетинг, финансы), а не отдельных людей (например, Джон Доу). Следовательно, для работы на уровне отдельных сотрудников организациям приходилось разворачивать инфруструктуру токенов, которая, как мы отметили выше, может оказаться обременительной. С помощью этой новой службы цифровые подписи отдельных сотрудников внедряются без необходимости самостоятельно управлять HSM (и без риска потери токенов сотрудниками).
Типичные приложения:
Будущие методы хранения ключей
Мы рассмотрели основные варианты, которые использовались в течение многих лет. Но кажется, что ничто в мире информационной безопасности, в том числе и хранение ключей, не застраховано от влияния IoT, так что разрабатываются новые варианты.
По мере того как все больше и больше устройств подключаются к сети с необходимостью аутентификации и безопасного обмена данными, многие разработчики и производители обращаются к решениям на основе PKI. В свою очередь, это приводит к новым соображениям, требованиям и технологиям защиты закрытых ключей. Ниже приведены две тенденции, которые мы видим в этой области.
Доверенный платформенный модуль (TPM)
Модули TPM сами по себе не новы, но всё чаще их используют для защиты закрытых ключей. Доверенный платформенный модуль можно использовать для хранения (или переноса) корневого ключа и защиты дополнительных ключей, созданных приложением. Ключи приложений нельзя использовать без TPM, что делает его очень полезным методом аутентификации для оконечных точек, таких как ноутбуки, серверы и производители устройств Интернета вещей. В то время как многие ноутбуки уже поставляются с TPM, пока эта технология не слишком широко используется в корпоративном секторе. Однако в мире IoT они часто применяются для безопасной индентификации устройств как аппаратный корень доверия.
IoT создал проблему, когда много анонимно взаимодействующих устройств облегчают хакерам перехват сообщений или имперсонификацию устройств. Модуль TPM внедряется ещё на этапе производства для защиты криптографического ключа и, следовательно, для надёжной идентификации устройства.
Мы тесно сотрудничаем с Infineon для разработки решений Интернета вещей, сочетающих идентификацию устройств на основе PKI с корнями доверия на основе TPM. Для получения дополнительной информации ознакомьтесь с подтверждением концепции: «Безопасная аутентификация и управление оборудованием с помощью облачных служб сертификатов GlobalSign и OPTIGA TPM от Infineon.»
Физически неклонируемые функции (PUF)
Технология физически неклонируемых функций (PUF) — это сдвиг парадигмы в защите ключей. Вместо хранения ключей (с вероятностью физической атаки) они генерируются из уникальных физических свойств статической памяти SRAM конкретного чипа и существуют только при включении питания. То есть вместо надёжного хранения закрытого ключа один и тот же ключ восстанавливается снова и снова по требованию (пока устройство не выйдет из строя). Этот ключ гарантированно уникален, потому что при генерации используется присущая неконтролируемая неупорядоченность в кремниевой структуре чипа.
Технология PUF в сочетании с доверенной средой исполнения (TEE) — привлекательное решение, если требуется недорогая, простая в интеграции и ультра-безопасная защита ключа. PUF вместе с PKI составляют исчерпывающее решение для идентификации.
Наш партнёр Intrinsic ID разработал такую систему подготовки ключа на основе SRAM PUF, которая производит уникальные, защищённые от подделки и копирования идентификаторы устройств на аппаратном уровне. Используя наши службы сертификации, мы переводим эти идентификаторы в цифровые удостоверения, добавляя возможности PKI. Таким образом, каждому устройству присваивается уникальная, защищённая от клонирования пара ключей, которая не хранится на устройстве в выключенном состоянии, но устройство способно воссоздать этот ключ по запросу. Это защищает от атаки на выключенное устройство.
Дополнительно о нашем совместном решении для идентификации
устройств Интернета вещей см. недавний вебинар: «Стойкие идентификаторы устройств с сертификатами на основе SRAM PUF».
Не теряйте (секретные) ключи от своей крепости!
Хранение закрытого ключа не должно быть чёрной магией. В конечном счёте, правильный вариант зависит от того, кто и для чего использует сертификаты, какие нормы приходится соблюдать, какова цена, текущее окружение и внутренние ресурсы. Надеюсь, эта статья поможет в вашем решении.
_______________________________________________________
АКЦИЯ GLOBALSIGN: Wildcard SSL + 1 ГОД В ПОДАРОК
Защитите все субдомены одним сертификатом!
Экономьте до 30 тысяч рублей при покупке сертификата Wildcard SSL на 2 года!
Промо-код: WC001HRFR
Акция действует для подписчиков блога GlobalSign до 15 июня 2018 г.
Дополнительную информацию вы можете получить у менеджеров GlobalSign по телефону: +7 (499) 678 2210 либо заполнив форму на сайте с указанием промо-кода.
SSL.com предоставляет широкий выбор SSL /TLS сертификаты сервера для сайтов HTTPS, в том числе:
Требования
Файлы P7B нельзя использовать для непосредственного создания файла PFX. Файлы P7B должны быть преобразованы в PEM. После преобразования в PEM выполните описанные выше шаги, чтобы создать файл PFX из файла PEM.
Видео
Команда поддержки SSL
Связанные как Tos
Генерация запроса на подпись сертификата вручную (CSR) Использование OpenSSL
Включить подсистему Linux и установить Ubuntu в Windows 10
Экспорт сертификатов и закрытого ключа из файла PKCS # 12 с помощью OpenSSL
Установите OpenSSL в Windows с помощью Cygwin
Подпишитесь на рассылку новостей SSL.com
Что такое SSL /TLS?
Подпишитесь на рассылку новостей SSL.com
Не пропустите новые статьи и обновления с SSL.com
сертификаты
поддержка
программы
компания
Copyright © SSL.com 2021. Все права защищены.
Мы используем файлы cookie, чтобы дать вам лучший опыт на нашем сайте.
Обратите внимание, что файлы cookie, необходимые для работы, не могут быть отключены.
Этот веб-сайт использует файлы cookie, чтобы мы могли предоставить вам наилучшие возможности для пользователей. Информация о файлах cookie хранится в вашем браузере и выполняет такие функции, как распознавание вас, когда вы возвращаетесь на наш сайт, и помогает нашей команде понять, какие разделы сайта вы считаете наиболее интересными и полезными.
Для получения дополнительной информации читайте наш Cookie и заявление о конфиденциальности .
Этот сайт использует Гугл Аналитика & Statcounter собирать анонимную информацию, такую как количество посетителей сайта и самых популярных страниц.
Включение этих файлов cookie помогает нам улучшить наш веб-сайт.
Пожалуйста, сначала включите Strictly Necessary Cookies, чтобы мы могли сохранить ваши предпочтения!