pfx формат
pfx это бинарник , то есть двоичный файл .
В pfx хранится открытый ключ и закрытый ключ.
Создаем pfx файл
Создается pfx на openssl таким образом (из файла .)
Но есть нюанс leaf.pem.cer должен быть в формате PEM (а может быть и в DER).
Еще нюанс , что при создании будет запрошен пароль (который не стоит забывать), или можно пароль не указать.
Примечание: кстати естественно этот пароль не является частью закрытого или открытого ключа и хранится где-то отдельно.
Теперь пробуем вывести информацию из pfx файла
openssl pkcs12 -info -in leaf.pfx
или так
openssl pkcs12 -info -in leaf.pfx -passin pass:»1234″
При извлечении информации из pfx файла будет затребован пароль и самое интересное не один .
Первый пароль откроет информацию по данным leaf.pem.cer :
данные leaf
открытая часть ключа leaf
данные intermediate.chain.pem
и открытая часть ключа intermediate.chain.pem
Второй пароль откроет информацию по какому-то закрытому ключу.
——BEGIN ENCRYPTED PRIVATE KEY——
.
——END ENCRYPTED PRIVATE KEY——
Вывод информации из pfd с наличием русских символов
Выше явно происходит затык на строке UTF8 с русскими буквами (friendlyName . ) .
pkcs12 -export -in «some.pfx» -out «newfile.pem»
К сожалению бывает есть файл pfx , а установить его с закрытой частью ключа на ПК никак не получается стандартными способами, например:
Как изменить пароль .pfx файла?
Три простых шага для изменения пароля файла с сертификатом и закрытым ключом.
2020-06-22 менее 1 мин на чтение
Алексей Комаров
Фанат кибербезопасности. Увлекаюсь маркетингом.
В случае необходимости изменения пароля от имеющегося файла .pfx можно воспользоваться следующими командами, введёнными в Терминале.
В примере ниже предполагается, что имеющийся сертификат и закрытый ключ хранятся в файле cert.pfx, а файл с новым паролем будет сохранён в файле newcert.pfx
-
Экспортируем имеющийся сертификат и закрытый ключ в .pem файл без пароля, указывая текущий пароль:
Пароль на pfx файл что это
В случае необходимости изменения пароля от имеющегося файла .pfx можно воспользоваться следующими командами, введёнными в Терминале.
В примере ниже предполагается, что имеющийся сертификат и закрытый ключ хранятся в файле cert.pfx, а файл с новым паролем будет сохранён в файле newcert.pfx
-
Экспортируем имеющийся сертификат и закрытый ключ в .pem файл без пароля, указывая текущий пароль:
Варианты хранения криптографических ключей
Продолжает расти популярность решений на основе PKI — всё больше сайтов переходят на HTTPS, предприятия внедряют цифровые сертификаты для аутентификации пользователей и компьютеров, S/MIME доказывает свою состоятельность и для шифрования электронной почты, и как способ проверки источника сообщений для противодействия фишингу. Но шифрование и аутентификация в этих приложениях практически бессмысленны без правильного управления ключами.
Каждый раз при выдаче цифрового сертификата от центра сертификации (ЦС) или самоподписанного сертификата нужно сгенерировать пару из закрытого и открытого ключей. Согласно лучшим практикам, ваши секретные ключи должны быть защищены и быть, ну… секретными! Если кто-то их получит, то сможет, в зависимости от типа сертификата, создавать фишинговые сайты с сертификатом вашей организации в адресной строке, аутентифицироваться в корпоративных сетях, выдавая себя за вас, подписывать приложения или документы от вашего лица или читать ваши зашифрованные электронные письма.
Во многих случаях секретные ключи — личные удостоверения ваших сотрудников (и, следовательно, часть персональных данных организации), так что их защита приравнивается к защите отпечатков пальцев при использовании биометрических учётных данных. Вы же не позволите хакеру добыть отпечаток своего пальца? То же самое и с секретными ключами.
В этой статье мы обсудим варианты защиты и хранения закрытых ключей. Как вы увидите, эти варианты могут незначительно отличаться в зависимости от типа сертификата(ов) и от того, как вы его используете (например, рекомендации для сертификатов SSL/TLS отличаются от рекомендаций для сертификатов конечных пользователей).
Хранилища сертификатов/ключей в ОС и браузерах
Примеры: хранилище сертификатов Windows, связка ключей Mac OS
В некоторых операционных системах и браузерах есть хранилища сертификатов или ключей. Это программные базы данных, которые локально на вашем компьютере хранят пару из закрытого и открытого ключей как часть сертификата. Такое хранение ключей довольно популярно: многие приложения автоматически сразу ищут ключи здесь, и не нужно вручную каждый раз указывать файл сертификата, так что это довольно удобный вариант.
Ещё один плюс такого варианта — его довольно легко настраивать. Вы можете включить/отключить экспорт закрытого ключа, включить для него надёжную защиту (ввод пароля при каждом использовании сертификата), и можно создать резервные копии, если закрытый ключ экспортируется. Кроме того, при включении роуминга профилей в Windows сертификат привязывается к профилю и становится доступным при входе на другой компьютер с этим профилем.
Если решите выбрать такой вариант, то следует учесть несколько аспектов. Во-первых, даже если пометить закрытый ключ как неэкспортируемый, некоторые утилиты могут обойти эту защиту (то есть невозможность экспорта не гарантирована). Кроме того, если кто-то работал под вашей учётной записью, а вы не включили сильную защиту закрытого ключа (пароль при использовании сертификата), то они могут использовать ваш сертификат. Наконец, если ваш закрытый ключ помечен как экспортируемый, то кто-нибудь за вашим компьютером сможет экспортировать его. Даже если у вас включена защита секретного ключа, при экспорте пароль не спрашивается.
И последнее: Chrome и IE используют хранилище сертификатов Windows, в то время как у Firefox собственное хранилище сертификатов (от Mozilla). Это значит, что если вы импортируете сертификат в хранилище Windows, то Chrome и IE автоматически найдут его, а Firefox нет.
Типичные приложения:
- Приложения для цифровой подписи (например, Adobe Acrobat, Microsoft Outlook и Office будут обращаться в хранилище сертификатов Windows [пользовательское]).
- Сервер Microsoft IIS тоже ищет SSL-сертификаты в хранилище сертификатов Windows [общем для компьютера].
- Аутентификация клиента (пользователя или компьютера), в зависимости от настроек, чаще всего обращается к хранилищу сертификатов Windows.
- Подпись кода в Windows (приложения и драйверы).
Файлы .pfx и .jks (хранилища ключей)
Файлы PKCS#12 (.pfx или .p12) и .jks* (созданные инструментом Java Keytool) содержат ваши закрытый и открытый ключи. В отличие от локальных хранилищ для ОС и браузеров, эти файлы могут размещаться практически в любом месте, включая удалённые серверы, и всегда защищены паролем (то есть каждый раз при использовании своего секретного ключа нужно ввести пароль). Другая привлекательная особенность: поскольку это просто файлы, то несложно разослать копии для нескольких человек, которым нужно использовать сертификат.
Если решите сохранить файл на удалённом сервере, то следует особенно позаботиться об ограничении доступа к нему. Если кто-то получит доступ, то сможет использовать ваш сертификат. Аналогично, следует быть особенно осторожным с лёгким копированием и распространением этих файлов. Хотя это и большое удобство для вас, но одновременно и злоумышленнику будет просто сделать копию, если он получит доступ к вашему хранилищу ключей. Пароль закрытого ключа по-прежнему необходим для эффективного использования скопированного файла. Это еще одна причина, чтобы использовать надёжные пароли из 15-ти и больше символов, содержащие заглавные буквы, цифры и специальные символы. С этим вариантом хранения нужно учитывать ещё одну вещь: на конечного пользователя накладывается больше ответственности с точки зрения того, где находится файл и правильно ли он хранится.
Если вы не можете использовать криптографическое оборудование или хранилище ключей Windows (описано выше), но всё же хотите повысить безопасность (вместо того, чтобы просто разместить файл хранилища ключей на компьютере), то можно записать этот файл на флэшку, которая будет лежать в безопасном месте. Конечно, здесь теряется некоторое удобство, так что если нужно часто использовать подпись, то вы скорее захотите хранить файл локально для облегчения доступа.
Типичные приложения:
- Подписание кода Windows или Java. и IRS IDES используют .pfx для безопасной связи с американскими госслужбами.
- Некоторые веб-серверы (например, Apache Tomcat или Jboss).
Криптографические токены и смарт-карты
Как вскользь упомянуто выше, можно повысить безопасность, если хранить секретный ключ на отдельном оборудовании. Но есть большая разница между использованием криптографических токенов или смарт-карт и стандартных флэш-накопителей. С криптографическим оборудованием ключ генерируется на самом оборудовании и не экспортируется. Закрытый ключ никогда не покидает устройство, что сильно затрудняет постороннему получение доступа и компрометацию.
Примечание: если вы хотите дополнительно обезопасить закрытый ключ, который уже сгенерирован ранее (т. е. не на самом токене), то можно импортировать .pfx-файл на токен, а затем удалить оригинальный .pfx.
С токеном каждый раз при использовании сертификата нужно вводить пароль. Это значит, что даже если кто-то получит ваш токен, ему всё равно понадобится пароль. Хранение ключа в токене означает, что вы можете безопасно использовать один и тот же сертификат на нескольких компьютерах без необходимости создания нескольких копий и прохождения процесса экспорта/импорта. Криптографическое оборудование соответствует FIPS, что требуется для некоторых отраслевых и государственных регламентов.
Конечно, есть некоторые другие соображения, которые следует иметь в виду, если вы решите выбрать такой вариант. Кроме дополнительных сложностей управления токенами, такой вариант может не работать с автоматическими сборками из-за требования ввести пароль при каждом использовании сертификата. Также нет никакого способа создать резервную копию сертификата, поскольку закрытый ключ не экспортируется (недостаток дополнительной безопасности). Наконец, в некоторых сценариях такой вариант хранения просто невозможен. Например, если специализированные устройства не поддерживают токены или смарт-карты. Или в ситуациях, когда сотрудники не имеют физического доступа к компьютеру, а работают с удалённых терминалов.
Типичные приложения:
Как правило, все варианты использования, перечисленные для хранилищ в ОС/браузере (подпись документов и кода, аутентификация клиента, Windows IIS), поддерживают крипто-токены или смарт-карты — если есть соответствующие драйверы. Однако это не всегда практично (например, в веб-серверах или автоматизированных системах сборки для подписи кода, которые будут требовать ввод пароля каждый раз при применении подписи).
Соответствие нормативным требованиям — одна из основных причин использования криптографических токенов.
- Обязательно для подписания кода расширенной проверки (EV) в соответствии с рекомендациями форума CA/Browser.
- Рекомендуется для стандартной подписи кода в соответствии с минимальными требованиями CA Security Council. Центры сертификации обязаны рекомендовать криптографическое оборудование в качестве основного варианта выдачи сертификатов. Если криптографическое оборудование не выдаётся, клиент должен подписать соглашение, что будет хранить закрытый ключ на каком-то съёмном оборудовании (которое вынимается после подписания).
- Требуется для цифровой подписи и получения доверенного статуса в программах Adobe, в соответствии с требованиями Adobe Approved Trust List (AATL).
- Отраслевые правила, такие как CFR 21 часть 11 от FDA и требования к цифровой подписи в отдельных странах часто говорят о секретном ключе, который находится в единоличном владении собственника. Хранение на криптографическом оборудовании отвечает этим требованиям.
Аппаратные криптографические модули (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 (и без риска потери токенов сотрудниками).
Типичные приложения:
- Подпись документов или кода в большом количестве.
- SSL (в зависимости от конфигурации сервера).
- Инфраструктура ЦС для работы собственного ЦС (корневого ЦС, подчинённого ЦС, сервера меток времени RFC 3161) в офлайне или онлайне (корневой ЦС, как правило, работает в офлайне).
Будущие методы хранения ключей
Мы рассмотрели основные варианты, которые использовались в течение многих лет. Но кажется, что ничто в мире информационной безопасности, в том числе и хранение ключей, не застраховано от влияния 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 либо заполнив форму на сайте с указанием промо-кода.
Изменение пароля в файле p12
Мне был отправлен файл p12 от клиента с сертификатом push.
могу ли я изменить пароль этого файла p12 без каких-либо последствий, и если да, могу ли я использовать что-то вроде этого:
Я нашел на этом сайте здесь
3 ответов
не будет никаких проблем.
PFX-это зашифрованный контейнер, изменение пароля контейнера не повлияет на сертификаты внутри контейнера.
Я просто наткнулся на этой страница. Это работает?
чтобы избежать мертвых ссылок, вот содержание сообщения в блоге:
с помощью следующей процедуры вы можете изменить свой пароль на .сертификат pfx с использованием openssl.
экспорт текущего сертификата в тип PEM без пароля: [user@hostname]>openssl pkcs12-in mycert.pfx-out tmpmycert.УГР -узлов Введите Пароль Импорта: MAC проверено OK
преобразовать PEM без пароля для нового файла pfx с паролем: [пользователь@хост]в OpenSSL pkcs12 из -экспортно-из mycert2.pfx-файл -в tmpmycert.УГР Введите Пароль Экспорта: Проверка-Введите Пароль Экспорта:
удалить временный файл: [user@hostname] rm tmpmycert.Пем!—3—>
теперь вы закончили и можете использовать новый mycert2.pfx-файл с новым паролем.
нет, вы не можете сделать это без последствий.
Экспорт содержимого PKCS#12 с openssl потеряет информацию, которая не будет восстановлена при воссоздании PKCS#12.
Важны ли эти метаданные для вас, будет зависеть от вашего содержимого PKCS#12 и вашего варианта использования.
кажется, что нет способа просто «изменить пароль контейнера» с помощью openssl. (однако вы можете использовать Java keytool чтобы сделать это, как я объясняю позже.)
TL; DR: используйте это вместо команды openssl: keytool -importkeystore -srckeystore source.p12 -srcstoretype PKCS12 -srcstorepass:file ssp -destkeystore dest.p12 -deststoretype PKCS12 -deststorepass:file dsp -destkeypass:file dsp
в OpenSSL
вот сравнение между воссозданным PKCS#12 и его оригинальным, из старого (и недействительного) немецкого хранилища ключей для входа в систему для тестирования.
в моем случае PKCS#12 воссоздан таким образом больше не действителен/работает для предполагаемого приложения (вход на основе сертификата), поэтому мне пришлось найти другой решение.
краткий обзор (оригинал, затем вновь создаваемого файла):
и теперь разница между оригинальной экспортировать содержимое PEM-файл и повторно экспортировать Пэм вновь созданного файла PKCS#12. (Я отредактировал некоторые строки base64, а также переупорядочил данные PEM в выходных данных чтобы сделать разницу короче, а изменения более очевидными.)
Вы можете видеть, что у оригинала было два закрытых ключа (signaturekey и encryptionkey), в то время как новый имеет только один, как а также потерянные метаданные на пакетах сертификатов. Также обратите внимание, как localKeyID ‘s были изменены:
кроме потерянных метаданных,потеря закрытого ключа при импорте здесь, кажется, на самом деле довольно проблематично для меня. Поэтому обязательно протестируйте свой новый PKCS#12 и, возможно, создайте резервную копию старого в безопасном месте!
Протестировано с помощью
keytool
keytool является ключом и утилитой управления сертификатами и является частью Java JRE, для управления хранилищем ключей Java. В этом случае я использую версию OpenJDK.
Вы можете найти это (в Linux) как /usr/bin/keytool , или в вашей установке Java, например, в /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/keytool .
С keytool вы можете изменить только пароль контейнера (keystore password), не касаясь каких-либо клавиш внутри (что, вероятно, не то, что вы хотите, хотя):
теперь мы меняем пароль контейнера: это перезаписывает старый файл
и сравните результаты:
так keytool обновлено число итераций, но информация псевдонима ключа (encryptionkey/signaturekey) и порядок файлов в контейнере сохранены.
заметьте, однако, что это только изменяет пароль хранилища ключей PKCS#12, это не нажмите пароли любых зашифрованных закрытых ключей. Это полезно, если вы используете PKCS#12 для хранения различных ключи с разными паролями шифрования. Но это также означает, что вы должны помнить все из них, и вы больше не можете экспортировать эти ключи с помощью OpenSSL, поскольку openssl может обрабатывать только ключи, которые имеют тот же пароль, что и контейнер PKCS#12:
вы можете экспортировать сертификаты только из этого файла, используя -nokeys :
наконец-то, чтобы фактически изменить пароль хранилища ключей / контейнера и зашифрованный пароль (ы) ключа внутри (Что, скорее всего, то, что вы хотите), вы можете использовать этот магический вызов:
здесь SRCFILE и DSTFILE ваши файлы PKCS#12 соответственно, а ssp и dsp файлы, в которые вы безопасно написали свои исходные и dest-пароли ранее (keytool также может читать из переменных среды с помощью :env вместо :file . И вы можете сдать пароли в командной строке, но помните, что является небезопасным и вошел в историю вашей оболочки.)
после повторного создания PKCS#12 вы можете проверить, что метаданные и порядок содержимого были сохранены:
(опять же, я отредактировал некоторые строки base64 PEM для краткости)
и мы видим, что закрытые ключи были повторно зашифрованы (обновленная метка времени, показанная keytool), но по сравнению с выводом openssl, на этот раз, помимо изменения количества итераций, только localKeyID изменился.
Все еще там, и в первоначальном порядке. Гораздо лучше!
достаточно ли это близко к исходному файлу, опять же, зависит от вашего варианта использования. Обновленный счетчик итераций лучше защищает от атак грубой силы на ключах, но потенциально может быть фатальным, если вам нужно использовать их с старый браузер или ос, которые не могут обрабатывать такие высокие числа итераций. (Поскольку они имеют возраст IE 4.0 и WinNT, однако это не должно быть проблема в большинстве случаев.)
используя эту процедуру с keytool , я мог бы изменить пароль моих ключей PKCS#12 таким образом, чтобы он все еще был полезен и действителен для моего приложения.
Создание PFX сертификата из отдельных файлов с открытым и закрытым ключом
Очень часто при покупке коммерческого сертификата провайдер услуги предоставляет нам сертификат в PEM формате, т.е. отдельно предоставляется файл, содержаший сам сертификат (открытй ключ) и отдельной файл с закрытым ключом. Для того, чтобы импортировать такой сертификат в хранилище сертификатов Windows компьютера предварительно необходимо создание PFX сертификата. При этой процедеру открытый и закрытый ключ сертификата “склеиваются” в один файл, который в последующем можно без проблем импортировать в хранилище сертификатов сервера Windows.
Ниже мы рассмотрим один из способов конвертирования сертификата из PEM формата в PFX. В качестве инструмента для конвертирования мы будем использовать OpenSSL.
Необходимый инструмент
Создание PFX сертификата а из PEM сертификата штатными средствами Windows “из коробки” не поддерживается. Соответственно, мы будем использовать сторонее решение – OpenSSL for Windows.
Переходим по указанной выше ссылки и загружаем дистрибутив программного продукта:
Копия дистрибутива от 03.09.2021 доступна ниже:
Выполняем установку дистрибутива. В случае успешной установки в директории, которую вы указали при установке будет примерно следующий набор файлов:
Процедура создания PFX сертификата
Для того, чтобы выполнить непосредственную конвертацию PEM сертификата в PFX выполните следующие действия:
1. Запустить командную строку от имени администратора.
2. Перейдите в директорию bin в папке с установленным дистрибутивом OpenSSL:
3. Выполните следующую команду:
in – путь до файла с открытым ключом,
inkey – путь до файла с закрытым ключом,
out – путь до файла, в который будет конвертирован сертификат.
4. Если ваш PEM файл был защищен парольной фразой, то openssl напишем вам соответствующее сообщение. Далее вам будет необходимо указать вашу парольную фразу, которой был защищен закрытый ключ:
5. Указываем парольную фразу, которой будет защищен наш итоговый PFX файл:
6. Дожидаемся окончания процедуры конвертирования сертификата.
После завершения процедуры конвертирования в указанной нами папке будет сгенерирован сертификат в PFX формате:
Проверка PFX сертификата
Для того, чтобы проверить правильно ли было выполнено конвертирование сертификата в PFX формат, вы можете импортировать его либо в личное хранилище сертификатов текущего пользователя, либо импортировать сертификат в хранилище локального компьютера.
В результате успешного импорта мы увидим сертификат в том хранилище, куда вы выполнили импорт. Дополнительно с свойствах сертификата будет сообщение о том, что в нем присутствует закрытый ключ:
Заключение
В текущей статье мы рассмотрели процедуру конвертирования сертификата из PEM формата (с отдельными файлами для открытого и закрытого ключа) в PFX формат (файл, который включает в себя как открытый, так и закрытый ключ). Для конвертирования сертификата мы использовали утилиту OpenSSL.